Axios爆雷：一行代码如何偷走你的云账号

Jason Saayman盯着屏幕上的漏洞利用链，意识到这不是普通的原型污染。一个开发者自以为安全的硬编码请求，正在被恶意属性悄悄劫持，最终指向AWS的元数据服务。

正方：这不是Axios的锅，是生态系统的结构性漏洞

支持这一观点的人会指出，CVE-2026-40175的核心触发点并不在Axios本身。漏洞利用的前提是攻击者已通过其他npm包完成了原型污染（prototype pollution），Axios只是在配置合并阶段"被动接收"了这些恶意属性。

从代码层面看，问题出在lib/adapters/http.js对请求头的处理逻辑。当第三方库污染了Object.prototype，Axios的配置对象会继承这些属性，随后在未经过滤的情况下将其合并进HTTP头。真正导致请求走私的，是换行符（CRLF）未被转义——但这属于HTTP协议层面的通用风险，而非Axios独有的设计缺陷。

更关键的辩护点是：IMDSv2的绕过需要多重条件叠加。攻击者不仅要完成原型污染，还要精准构造能注入会话令牌头的走私请求，最后还要在令牌有效期内完成凭证窃取。这种复杂度意味着，单纯修复Axios的头部校验并不能根除风险，供应链上游的污染源头才是病灶。

这一派观点的潜台词是：把安全责任压给单一库的作者，会掩盖npm生态中更广泛的信任危机。

反方：Axios的合并策略就是攻击放大器

反对者会立即反驳：上述辩护恰恰暴露了Axios的设计傲慢。原型污染在npm生态中并非新鲜事物，Axios作为月下载量过亿的顶级依赖，却在配置合并环节采用"全继承"模式，且长期缺乏对头部值的字符白名单校验——这不是被动受害，是主动制造的攻击面。

漏洞的严重性在于"零交互"特性。开发者编写的硬编码请求，理论上是最安全的代码形态：没有用户输入，没有动态拼接，攻击面趋近于零。但CVE-2026-40175证明，只要运行环境中存在被污染的依赖，这些"安全代码"会自动转化为武器。Axios的配置合并机制，本质上把原型污染从"本地风险"升级为"网络边界突破工具"。

IMDSv2的绕过更具杀伤力。该版本的安全设计明确要求带令牌的会话请求，而标准的服务端请求伪造（SSRF）无法生成这些令牌。但Axios的头部注入漏洞允许攻击者在走私请求中直接植入令牌头，绕过了AWS的安全控制逻辑——这不是"借道"第三方漏洞，是Axios特有的协议操作能力被滥用。

1.15.0版本的修复方案也侧面印证了反方观点：严格的头部校验机制本可以更早引入，为何等到PoC公开后才紧急上线？

判断：这是"默认不安全"设计哲学的代价

双方都有事实支撑，但反方更接近问题的本质。Axios的漏洞不是孤立的编码失误，而是JavaScript生态中"便利优先于安全"传统的集中爆发。

配置对象的深度合并是Axios的核心卖点——开发者可以分层覆盖默认设置，用极少的代码实现灵活的请求行为。但这种便利建立在两个危险假设之上：一是原型链是可信的，二是合并后的值无需二次校验。CVE-2026-40175同时击穿了这两个假设。

更值得警惕的是漏洞的"沉默性"。原型污染发生后，恶意属性不会触发任何异常，直到它们被Axios写入HTTP头、完成请求走私、窃取IAM凭证——整个链条在日志中几乎不可见。对于依赖云原生架构的团队，这意味着攻击者可能在数周内完全控制生产环境，而监控体系毫无察觉。

修复建议的层次也揭示了责任归属。官方不仅要求升级Axios，还强制要求审计完整的依赖图谱——这实际上承认了单一库的边界防护已不足够。但当Axios作为基础设施级依赖被数百万项目引用时，其设计选择本身就塑造了生态的安全基线。把"供应链安全"作为免责理由，是把系统性风险转嫁给下游开发者。

1.15.0的严格校验是一种迟到的纠偏：头部值含非法字符时立即抛出安全错误，阻断利用链的关键节点。但这只是止损，而非反思。下一个类似的漏洞，可能藏在另一个追求"无缝体验"的流行库中。

对于正在运行的系统，建议做三件事：立即扫描依赖树中的原型污染风险（重点关注lodash、merge等高频目标）；在网关层增加对异常头部模式的检测；对AWS元数据服务的访问实施额外的网络分段——即使凭证泄露，也能限制横向移动的空间。