你本地跑着一个轻量文件服务器，以为只是临时传个文件。但攻击者能让你的浏览器，在不知情的情况下往服务器写任意文件。

漏洞怎么来的：一次"修了一半"的安全补丁

打开网易新闻 查看精彩图片

goshs 是一个用 Go 写的单二进制文件服务器，主打轻量、开箱即用。开发者之前打过安全补丁，但漏了关键一环。

问题出在两个配置的组合：

第一，HTTP PUT 方法没有跨站请求伪造（CSRF）保护。浏览器发 PUT 请求时，服务器不校验请求来源是否合法。

第二，跨域资源共享（CORS）配置过于宽松，无条件反射 Origin 头。这意味着任何网站都能被浏览器"信任"为合法来源。

攻击者构造一个恶意网页，诱导已登录 goshs 的用户访问。用户的浏览器自动携带身份凭证，向本地或内网的 goshs 服务器发起 PUT 请求——文件就这么写进去了。

正方：这设计本身就有问题

安全视角的批评很直接：单文件服务器常被用在临时场景，用户安全意识最低。

开发者打了补丁却漏掉 PUT 方法，属于典型的"修一半"。CORS 无条件反射 Origin 更是基础错误，相当于主动拆除同源策略的防护墙。

CVSS 8.8 的高分说明攻击成本低、影响大。不需要认证，不需要用户交互，浏览器自动完成攻击——这是 Web 安全里最危险的组合之一。

反方：工具定位决定了取舍

另一种声音认为，goshs 的设计哲学就是"零配置、快上手"。

严格的 CSRF 和 CORS 策略需要额外配置，与"单文件、开箱即用"的目标冲突。很多用户跑在隔离网络或本地回环，攻击面本就有限。

开发者 2.0.3 版本已修复，响应速度不算慢。安全与易用的平衡，从来都是工具类产品的难题。

我的判断：临时工具正在成为长期隐患

这个漏洞的真正价值，在于暴露了一类被忽视的风险模式。

开发者越来越依赖"临时方案"：本地跑个文件服务器、内网开个调试接口、快速搭个测试环境。这些工具的设计假设是"用完即走"，但实际情况是——它们往往长期运行，甚至暴露在意外可达的网络位置。

goshs 的漏洞组合并不复杂，却精准击中了这类场景：用户没有安全预期，工具没有默认防护，攻击者利用浏览器自动行为完成利用。

更值得追问的是：多少类似工具还在用"零配置"作为卖点，同时把安全责任完全推给用户？当"轻量"成为优先于"安全"的默认选择，这类漏洞会反复出现。

2.0.3 版本已修复。但如果你本地还跑着旧版本，现在就该检查。