过去两个星期，如果你关注 DSH（DeepSeek Harness）这个话题，大概率刷到过同一类教程：手机和电脑都装上 Tailscale，登录同一个账号，再执行一条反代命令，就能在手机上随时随地打开家里的 AI 智能体工作台，所谓"把 Agent 装进口袋"。这个项目有多火呢，8 月 13 日晚开源、MIT 协议，三天内 GitHub 星标就从 4.5 万冲到 14 万量级，我写这篇时仓库页面的实时数字已经超过 19 万。知乎
然后就是昨天的事：奇安信威胁情报中心披露，DeepSeek Harness 存在一个未授权远程代码执行漏洞，编号 QVD-2026-57410，评级极危，CVSS 9.8，POC 和技术细节均已公开，奇安信 CERT 已完成验证；目前没有 CVE 编号，也暂未观测到在野利用。知乎小红书
最扎心的一点是：这个漏洞真正影响的部署形态，恰恰就是这两周教程里最流行的"手机远控"玩法。我把小红书上流传的主流教程和奇安信点名的高危清单逐条对了一遍，结论先放在前面——四条路线，一条能留，一条加锁，两条要拆。
锁是怎么坏的
先给颗定心丸：默认安装相对安全。dsh 的 Web UI 默认绑定 127.0.0.1:3080，只监听本机回环，外部根本摸不到。知乎
问题出在门锁的构造上。dsh 的 Web 服务用 HTTP Host 请求头来判断"请求是不是来自本机"，以此守护 /api 后面的高权限 RPC 接口，而 Host 头是客户端可以随意填写的字段。知乎打个不太严谨的比方：这等于门锁不看人，只看门口贴的名片。
攻击链因此非常顺滑：攻击者注册一个指向自己服务器的虚假大模型提供者，再借这个假提供者驱动 dsh 的 Agent 工具（比如 bash）执行系统命令，最终以 dsh 服务进程的权限完全控制主机——全程不需要你的任何 API Key，也不需要真实模型。知乎bash 本来就是智能体工作台的产品功能，攻击者只是"借用"了这只现成的手。
四条路线，四种命运
我核对了近两周小红书、知乎、B站上流传的 DSH 远程教程，手机访问 DSH 的路线说来说去就四条。对照奇安信点名的高危部署清单，各自的命运不太一样。
路线一：tailscale serve 反代（教程主流）——可以留
流传最广的教程步骤是这样的：手机和电脑都安装 Tailscale 并登录同一账号；启动 DSH 时给命令加上白名单参数 --trusted-host，填你自己的 ts.net 域名；然后执行反代命令：tailscale serve --bg 3080。小红书之后手机浏览器里打开 https://你的机器名.ts.net/ 就能用了。
这条路线的关键在于：tailscale serve 只把服务开放给你自己的 tailnet，也就是你账号下的设备组成的加密私网，公网完全摸不到。用奇安信处置建议里的话说，这叫"只允许可信内网 IP 访问"，正是他们给"确需远程访问"场景开出的第一味药。需要提醒三件事：别顺手开 Funnel（见下一条）；别把不熟的设备拉进你的 tailnet；盯紧版本号和官方补丁的节奏。
路线二：tailscale funnel 公网暴露——建议立刻拆
Funnel 相当于在 serve 的基础上，给整个互联网开了一扇公开的门。8 月 24 日之前，它可以叫"方便给朋友演示"；在 POC 公开、补丁还没影的现在，把 dsh 挂上 Funnel，等于把你家电脑的 bash 挂到大街上，还贴了张"免钥匙入内"的告示。
自查方式：终端里执行 tailscale funnel status，看看自己是不是给 dsh 开过公开入口，开过的先关掉再说。
路线三：CF Tunnel、frp、端口转发——加把真锁再用
小红书那篇高热度直连笔记的评论区里，有条被顶得很高的建议：dsh 的话还是直接 cf 绑个域名 tunnel 搞定快。小红书CF Tunnel 确实省事，但它的本质是把服务映射到公网，和 frp、路由器端口转发一样，都落在奇安信点名的第一类高危部署里。如果你已经在用，或者打算用，请把真实身份认证加在反代层：mTLS、SSO、IP 白名单，至少来一样。知乎只靠 dsh 自己那把 Host 头的锁，现在是不设防。
路线四：改 0.0.0.0、Docker 端口映射——改回去
有人为了省事，把 dsh 的监听地址改成 0.0.0.0，或者用 Docker 时直接把 3080 映射到宿主机的非回环地址。热门教程自己都特意标了一句：不要改源码的 host 0.0.0.0。小红书这两种操作对应高危清单里的后两类：用 Docker 端口映射把服务转到非回环网络、套反向代理对外提供访问又没做严格校验。知乎结论只有一个：恢复成 127.0.0.1 监听，远程的事交给 serve。
"自己开门怪谁"这话，只说对了一半
现在各平台的评论区基本吵成两派。一派的高赞评论是：你家的密码锁在大门打开的时候可能不安全。小红书翻译一下：默认安装本来没事，你自己非要开门，被打了别怪锁。
另一派不买账：就算你严格按照文档只在 localhost 跑，任何能发 HTTP 请求到 127.0.0.1 的本地进程都能伪造 Host 头，绕过它的所谓"鉴权"，这不是用户自行暴露，是软件给你的锁本来就不防人。小红书
我的看法：两派各对一半。
"开门活该"派忽略的是，“开门"不是用户的滥用，而是产品预期内的正常路径——官方给 tailnet 域名准备了 --trusted-host 白名单参数，全网教程都在教怎么开门，插件生态里也有专门做远程接入的插件。产品一边教你开门，一边在锁坏掉之后说"谁让你开门的”，这个逻辑说不通。
"锁本来就坏"派也不用太恐慌：tailscale serve 这条私网路线，攻击者得先进得了你的 tailnet 才摸得到门，这一步本身就挡掉了公网上绝大多数的扫描和试探。风险不是零，但离"机器已经没了"还很远。
真正危险的组合只有一个：端口能被公网触达，而安全却依赖 Host 头判断。这个组合在 POC 公开、官方补丁未出的窗口期里，约等于裸奔。
生态里已经有人在补位：第三方插件 dsh-remote-mobile 的做法是给远程访问套一层真认证，不改 DSH 底层代码，扫码配对、密码登录二选一，RSA 加密传输，防暴力破解（连续输错自动锁定 IP）。小红书暴露路线要活下来，方向只能是这样：在门外面加一道真锁，而不是祈祷没人发现门。
自查清单，五分钟够
对照奇安信的处置建议，再补两条 Tailscale 特有的，一共五件事：
查监听地址：dsh 进程应只绑定 127.0.0.1（默认端口 3080）。
查 Docker：3080 这类管理端口，没有映射到宿主机的非回环地址。
查反代：前面挂了 Nginx 或网关的，先做 Host 头白名单校验，再补真实认证，mTLS、SSO、IP 白名单至少一样。
查 Tailscale：执行 tailscale funnel status，确认没给 dsh 开公网入口，开了先关。
查版本：目前确认受影响的版本是 0.1.1-rc.2，DSH 本身还在开发者预览阶段，盯紧官方安全公告和修复版本。知乎
另外，把 DSH 部署在云服务器上的朋友注意，这条路线这两周也不小众，知乎已经有"云服务器部署、后台运行、SSH 隧道与 Tailscale 远程访问"的完整指南。知乎请多查一项：云安全组里，3080 没有对 0.0.0.0/0 放行。
补丁落地前，盯三个信号
接下来真正值得跟进的只有三件事：DeepSeek 官方的补丁版本何时发布、CVE 编号何时分配、以及 POC 公开后是否出现在野利用。知乎截至发稿，这三件事都还没有确切消息，有进展值得第一时间跟进。
最后说一句不算多余的。回看 Harness 自己的设计哲学——审批、权限检查、沙箱全都做成可替换的插件——这次漏洞反而证明：当 Agent 的手越来越长，看门的那几层，恰恰最不该是可省略的插件。知乎Agent 框架天生握着 bash、文件系统和代码执行这些高权限能力，你把它从笔记本搬上服务器、装进 Docker、接进网络，安全模型就从"本地工具"变成了"互联网上的高权限入口"。网络隔离是这份保险里最便宜的一种，好在 tailscale serve 默认做的就是这件事。
你的 DSH 是哪条路线连的？自查完欢迎在评论区对个答案。
