一句话定义：HTTP2Shell 不是某一个漏洞的名字，而是一类攻击面的统称——攻击者构造一条“读法有歧义”的 HTTP 请求，让服务端的 HTTP 库或网关把它理解成别的东西，最终从“发数据”升级成“执行命令”，拿到一台 shell。名字来自早期在 Node 生态里被集中讨论的那批案例（Node2Shell），但问题本身跨语言、跨框架。
原理，用快递打个比方：前端反向代理是分拣员，后端业务是收件人。包裹上贴着“这箱是文件，重 3 公斤”。如果分拣员按“重 3 公斤”截断，收件人却按“文件结束标记”截断，同一辆车里就会多出半箱没人认领的货——而收件人会把那半箱当成下一单的指令。HTTP 里干这事的经典字段就是 Content-Length 和 Transfer-Encoding，两者同时出现、或 HTTP/1.1 转 HTTP/2 时头部被“重写”，前后两跳就可能各读各的。再往上一层，请求行、路径规范化、头部折行、URL 编码，都是容易出“两套读法”的地方。
攻击链通常这样走：暴露在公网的网关或框架 → 解析歧义（请求走私、头注入、路径混淆）→ 请求被“偷渡”到本不该被访问的内部服务 → 命中一个危险落点（命令拼接、模板渲染、反序列化、写文件）→ 拿到执行权 → 反弹 shell 回来。Shell 是终点，但前面每一环都是普通 HTTP 流量，WAF 和日志里看着很像正常请求。
为什么爆炸半径这么大：HTTP 库是每种语言的“标配依赖”，几乎没有一个栈能绕开；一个解析层的偏差，会在“网关→服务 A→服务 B”的链条上被逐跳放大；大量公司复用同一套中间件和基础镜像，一处出问题就是一片；而且内部服务通常默认信任“来自网关的流量”，等于把第二道门也开着。
| 概念 | 出问题的层次 | 最终效果 |
|---|---|---|
| SQL 注入 | 应用代码拼 SQL | 读写数据库 |
| SSRF | 应用代为发起请求 | 打通内网 |
| 请求走私 | 协议解析与转发 | 越权访问、缓存污染 |
| HTTP2Shell | 协议解析 + 下游危险落点 | 远程执行、拿 shell |
可以看到，请求走私常常只是 HTTP2Shell 攻击链的第一环。
自己怎么自查：先盘点 HTTP 栈——语言自带的 HTTP 库、框架、网关、反代、SDK，一个都别漏；在边界上统一解析口径，拒绝 Content-Length 与 Transfer-Encoding 并存的请求；HTTP/1.1 与 HTTP/2 互相转换的地方做严格规范化；给服务最小权限，限制出网，因为拿到执行权后攻击者第一件事往往是外连；日志里重点看重复头部、畸形请求行、超长头部。普通职场人这边，这类问题多半由云厂商和软件供应商修，个人要做的是及时更新、别在公网自建来路不明的代理。具体受影响组件与修复版本，以各项目官方公告为准。