TL博士在遇到 2026 年发现的第三个缓冲区溢出漏洞（根据 F5 的说法，如果没有 ASLR，则还存在远程代码执行漏洞）后，freenginx 的开发者 Maxim Dunin 决定采取措施，在向其产品写入数据之前添加变量大小检查。Nginx 随后也采用了这一特性，这让人燃起了希望，认为与此问题相关的新的 CVE 漏洞将被消除。
现在来说说细节。
6月19日 犯罪 Freenginx 在变量描述符中添加了一个 end 字段，用于指示缓冲区的结束位置。此前，缓冲区只有一个指向其起始位置的指针 (pos)，所需的长度是预先计算的（现在仍然如此），并且在数据复制到变量时，假定正确计算的长度能够保证数据完全放入缓冲区。然而，由于各种疏忽，这种做法在 2026 年 5 月已被证明是错误的两次。1 (linux.org.ru), 2 (linux.org.ru)这导致了缓冲区溢出和严重后果。现在，当创建变量的缓冲区时，指向其末尾的指针也会被填充，并且在将数据写入变量之前，如果数据超出缓冲区大小，请求处理将以一种可控的方式终止并抛出错误。这意味着长度计算错误可能仍然存在，但它们不会浪费内存；它们只会导致特定的 HTTP 请求失败。以下提交（2 (freenginx.org), 3 (freenginx.org)类似的保护措施也添加到了代码的其他部分，包括访问日志记录代码。该版本于7月7日发布。 Freenginx 1.31.3其中包括此修复程序。
7月15日，nginx 采用了这些提交（1 (github.com), 2 (github.com), 3 (github.com)（由于某种原因，链中的第二个和第三个被交换了位置），这个问题被分配给了 CVE-2026-42533F5 发布了官方版本 SA（f5.com）.
关于这次的具体漏洞：当使用带有提取参数的正则表达式的 map 指令时，该漏洞就会出现。至于触发该漏洞的其他条件，提交描述和 SA 中的文本略有不同：SA 指出，在执行同一个 map 指令之前，必须先计算一个特定的字符串，该字符串会使用 map 指令提取出的剩余参数。而在示例的提交描述中，在这些步骤之间，包含提取参数的变量也被清零了。尽管如此，这种情况在大多数运行中的 nginx 服务器上不太可能发生，因此该漏洞影响的用户很少。值得注意的是，针对这种情况的长度计算修复程序并没有包含在已提交的修改中（或者是我搜索得不够仔细？），目前只有一个保护机制，可以将问题转化为受控的 HTTP 请求失败。尽管 freenginx 在 7 月 19 日添加了一些修复程序（5bfb, 7622, b906）计算类似情况的长度，但目前还不清楚是否如此。
该漏洞出现在 nginx 0.9.6 版本中，修复程序包含在 freenginx 1.31.3、nginx 1.30.4 和 nginx 1.31.3 版本中。
nginx SA感谢众多个人独立报告此漏洞并遵守“协调披露标准”：
F5 感谢 AntAISecurityLab 的 Ming Xuan、DKD (@pidifn)、Ji'an Zhou 和 Zhen Yan，EVO.company 的 Rafael Gacek 和 Sergii Negodiuk，Calif.io 的 Lam Jun Rong，Winfunc Research (winfunc.com) 的 Mufeed VH，以及 Vexera AI (https://vexera.ai）、Tu Tran Dinh (@1w4y)、Stan Shaw (cyberstan)、qianshuidewajueji、zenneth (randomguy6407)、depthfirst 的 Zhenpeng (Leo) Lin、Lukas Johannes Moeller、Vodafone Türkiye 的 Melih Tolga Sahin、Ayoub Nabil Boubagrat (GitHub: @ayoubnabil) 和 Milan Jovic (Kljunowsky)，感谢他们独立地将此问题告知我们，并遵循了协调披露的最高标准。
在 freenginx 中，关于修复的相关信息实际上仅限于提交消息。 更新日志这个修复甚至没有被标记为“安全”或“漏洞修复”，而只是“功能”。显然，作者并不认为这个问题很严重。我们无法确定上述 F5 用户报告的问题与从 freenginx 复制的提交之间是否存在关联，也无法确定他们（或其他任何人）是否曾向 freenginx 的作者报告过这个问题。
来源： linux.org.ru
