最近 PCL 联机被 DDoS 打得挺惨，我看了一圈，感觉很多人没搞明白一件事：公共联机节点本质上就是个隧道/反向代理。它把可用节点公开列出来，等于给攻击者发 IP 清单，打节点就能让联机房间全挂。节点还是志愿者单点，没云厂商那种防护，被打穿太正常了。
而且联机和 VPN 底层技术上本来就差不多，都能建虚拟连接、转发流量。一个能转游戏流量的节点，改改配置就能转别的流量。所以云厂商普遍禁私搭 VPN/内网穿透，不是技术做不到，是怕节点被当跳板，最后节点主背锅。
然后我就想到 DeepSeek Harness（dsh）。这玩意儿是 Agent 运行框架，模型负责想，Harness 负责干：调工具、读文件、执行命令、发网络请求。问题就出在这。
dsh 的插件很多都能发请求，有的 web_fetch 连内网和云元数据地址都不拦，存在 SSRF。攻击者用提示注入忽悠一下，就能让 Agent 去访问内网或者转发流量。说白了，一个"能按指令访问任意 URL"的工具，原理上就是个简易反向代理，被诱导就能当跳板用。
更离谱的是 dsh 的 Web 服务本身没真正认证，只校验 Host 头，而 Host 头随便伪造。有披露说通过隧道/反代暴露到公网后，不用凭据就能建会话、执行命令。真到这一步，把服务器改成 VPN 节点或攻击跳板就没技术门槛了。
但刷 Token 只是表面。真正要命的是信息泄露和系统级攻击。
最直接的是会话记录和 API Key：那个认证绕过能让攻击者无凭据直接导走你存的对话记录；agent 又以你运行 dsh 的账号权限执行命令，能直接读 ~/.dsh 下的 API Key 文件。GitHub 上已经有真实案例，有人发现额度半夜被刷，排查后确认是共享主机上的 dsh Web 被本机其他账号直接打开，agent 利用该账号权限把 key 读走了。
更隐蔽的是"秘密值"被明文吐给 AI：dsh-agent-shell 插件的几个读屏出口会绕过打码层，把 vault 里的秘密值明文输出给模型。你通过 vault 管理的密码、Token，可能在一次普通交互里就漏了。
还有全盘文件读取。所谓"只读沙箱"，bwrap 配置是 --ro-bind / /，整个宿主文件系统都被挂进沙箱。插件注入没白名单，默认零审批，inject: [‘fs’,‘web’] 就等于"读秘密 + 外传"一条龙。你电脑上任何文件，只要运行 dsh 的用户有权限，沙箱里的代码就能读到。
系统级攻击这边，沙箱本身就是个摆设。workflow 工具本意是让脚本在 node:vm 里跑，但隔离一行代码就能突破：agent.constructor(‘return process’)() 拿到宿主 process 后，读写任意文件、执行任意命令，权限就等于你运行 dsh 的那个用户。如果 dsh 跑在 root 下（容器/CI 里很常见），bwrap 配置少了 --unshare-user，沙箱进程保留挂载能力，agent 执行 mount -o remount,rw / 就能把只读文件系统改成可写，任意写/删宿主文件。
最危险的是完整 RCE 链：恶意网页/仓库内容/抓取的文档 → 提示注入 → 模型调用 cordis_define + cordis_run（默认组合下零审批）-> vm 沙箱拿到宿主 exec → ctx.get(‘subprocess’).spawn(…)，没有任何 landlock/seatbelt/bwrap 拦截 → 无限制的宿主进程。攻击者能在你机器上落持久化后门，长期控制。
甚至"修复"本身也能被绕过：认证绕过漏洞的官方修复是改用签名 Cookie，但签名密钥就存在 $DSH_HOME/.credentials.yaml 里，和 API Key 同一个文件，沙箱里直接可读。攻击者伪造一个合法 Cookie 就能重新接管控制面，修复等于白修。
dsh 一般还是个人自建单点，没 DDoS 防护。PCL 那种流量能打垮公共节点，打 dsh 更轻松。甚至不用大流量，提示注入让 Agent 死循环、狂刷 Token，就能把资源耗干。
所以别觉得"我就挂个 dsh 玩玩"。公共隧道 + 网络插件 + 没认证的 Web 服务 + 单点部署，这几个叠一块，服务器既可能被打，也可能被改成跳板，还可能把你 API Key、vault 秘密、全盘文件、会话记录全读走，最后在你机器上执行任意命令、落后门。别拿自己服务器试，也别随便贡献自己没法审计的公共节点。官方自己都说 dsh 是实验性预览版，没经过安全审计，不建议当生产用。 别把 dsh 直接扔公网，别用反代绕过本地限制，插件默认禁网，要开就白名单，扔虚拟机/容器里跑。