TinyWeb 中的 HTTP请求走私漏洞CVE-2026-28497
TinyWeb 是轻量级、单文件、开源的 HTTP 服务器,由 Masiutin 开发维护,主打极简部署、低资源占用,支持 HTTP 和 HTTPS 协议。
一、基本情况
TinyWeb 是一款使用 Delphi 编写的高性能轻量级 Win32 Web 服务器,该系统专为嵌入式系统、小型服务场景以及开发测试环境设计。

TinyWeb 采用单进程 / 多线程架构,核心模块清晰,在路由器、物联网设备中作为轻量 Web 服务器,占用资源远低于 Nginx/Apache。
栋科技漏洞库关注到TinyWeb 2.03 之前版本内部字符串转整数例程(_Val)整数溢出漏洞,追踪CVE-2026-28497,CVSS 4.0评分9.3。
二、漏洞分析
CVE-2026-28497漏洞是存在于 TinyWeb 受影响版本中存在的整数溢出漏洞,源于字符串转整数转换例程(_Val 函数)整数溢出所致。
当服务器解析 HTTP 请求头中的 Content-Length 字段时,构造超长的数值触发溢出导致服务器对请求体长度的理解与前端代理不一致。
未授权远程攻击者利用漏洞实施 HTTP 请求走私攻击(Request Smuggling),绕过安全过滤机制、进行缓存投毒或实现未授权访问。
具体来说,该漏洞存在于 SRC\xBase.pas 文件的 _Val 函数中(第 2961-2979 行)。
SrvMain.pas 文件中的 StoI 函数会调用此方法解析 Content-Length 请求头,但该实现未在数字累加过程中检查 32 位整数溢出问题。
当传入超大的 Content-Length 值(如 4294967306)时,带符号 32 位整数会发生溢出,最终被解析为一个极小的正数(如 10)。
前端代理可能会转发完整的 4GB 数据载荷,但后端 TinyWeb 服务器仅读取 10 字节作为请求体,
剩余数据会滞留在套接字缓冲区中,并被解析为同一连接上后续 HTTP 请求的起始部分。
由于攻击者可绕过 Content-Length 长度限制实施 HTTP 请求走私攻击,在使用持久连接(Keep-Alive)的场景下,漏洞影响尤为严重。
三、POC概念验证
1、启动 TinyWeb 服务器;
2、发送构造的包含溢出 Content-Length 值的 HTTP 请求:
管理员已设置登录后刷新可查看3、服务器会将前 10 字节解析为第一个 POST 请求的请求体,剩余的「走私请求」内容则被当作全新的独立请求处理。
4、潜在攻击场景
(1)安全过滤器绕过:
攻击者可将针对受限路径的请求(如 POST /admin/delete)隐藏在指向公开资源的「无害请求」中进行走私。
由于前端仅能「识别」第一个请求,其安全过滤规则可能被绕过;
(2)Web 缓存投毒:
若系统启用前端缓存,攻击者通过请求走私触发服务器为热门资源返回恶意响应,缓存服务器存储该恶意响应并提供给其他正常用户;
(3)CL.0 走私:
在部分配置下,后端可能将溢出的 Content-Length 值判定为 0(或极小值),而前端仍按超大长度处理,导致前后端请求解析不同步;
(4)凭证窃取(请求劫持):
攻击者可走私一个「追加式」请求,使其附加到下一个合法用户的请求之后。
当合法用户发送包含会话 Cookie / 请求头的请求时,其数据会被追加到攻击者的走私请求中,导致用户数据泄露至攻击者控制的端点。
5、RFC 合规性与标准
根据 RFC 9110(第 8.6 节)和 RFC 9112(第 6.3 节),服务器禁止转发包含格式错误 Content-Length 头的报文。
Content-Length 的 ABNF 语法严格限定为「1*DIGIT」(仅数字),
任何包含非数字字符、负号或超出服务器整数类型可表示范围的值,均需判定为协议错误。
6、修复方案与最佳实践
升级至 v2.03 版本:该版本替换了所有不安全的整数解析逻辑,并实现了符合 RFC 标准的严格校验;
标准化请求头:部署反向代理(如 Nginx),在请求到达后端前标准化请求头,移除歧义或重复的 Content-Length 字段;
禁用 Keep-Alive:若无法立即打补丁,禁用持久连接可缓解部分请求走私风险(但会牺牲性能)。
四、影响范围
TinyWeb < 2.03
五、修复建议
TinyWeb >= 2.03
六、参考链接
管理员已设置登录后刷新可查看