TL;DRAfter encountering the third buffer overflow discovered in 2026 (and, according to F5, an RCE if there's no ASLR) while working with regexps and variables, freenginx developer Maxim Dunin decided it was time to stop it and added a variable size check to his product before writing data to it. Nginx has since copied this feature, giving hope that new CVEs related to this issue will be eliminated.
Now for the details.
June 19 was made commit in Freenginx, which adds an end field to the variable descriptor, indicating the end of the buffer. Previously, there was only a pointer to its beginning (pos), the required length was (and still is) calculated in advance, and by the time the data was copied to the variable, it was assumed that the correctly calculated length would guarantee that the data would fit into the buffer. Unfortunately, this has already proven to be incorrect twice in May 2026 due to various oversights.1 (linux.org.ru), 2 (linux.org.ru)), which led to buffer overflows and dire consequences. Now, when a variable's buffer is created, the pointer to its end is also filled, and before writing data to the variable, if the data doesn't fit, request processing will terminate with an error in a controlled manner. This means that length calculation errors may still persist, but they won't waste memory; they'll only fail the specific HTTP request. The following commits (2 (freenginx.org), 3 (freenginx.org)) similar protection was added to other parts of the code, including the access logging code. A version was published on July 7 freenginx 1.31.3, which includes this fix.
On July 15, these commits were picked up by nginx (1 (github.com), 2 (github.com), 3 (github.com), for some reason swapping the second and third in the chain), the problem was assigned CVE-2026-42533, and F5 released an official SA (f5.com).
Regarding the specific vulnerability this time: it manifests itself when using the map directive with regexps with extracted parameters. Regarding the other conditions required for it to trigger, the text in the commit description and the text in the SA differ slightly: the SA states that a certain string must be calculated next, which uses the extracted parameter left over from the map, before the result of that same map. In the commit description in the example, between these steps, the variable containing the extracted parameter is also zeroed out. Be that as it may, this is unlikely to occur in most running nginxes, and therefore the vulnerability affected few people. It's also worth noting that a fix for the length calculation specifically for this case isn't in the committed edits (or did I search poorly?), there is only a protection that turns the problem into a controlled HTTP request fail. Although some fixes were added to freenginx on July 19th (5bfb, 7622, b906) calculating the length for a similar situation, but it is not immediately clear whether this is the case or not.
The vulnerability appeared in version nginx 0.9.6, fixes were included in versions freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
The nginx SA thanks a number of individuals for independently reporting the vulnerability and adhering to "coordinated disclosure standards":
F5 acknowledges Ming Xuan, DKD (@pidifn), Ji'an Zhou, and Zhen Yan of AntAISecurityLab, Rafael Gacek, Sergii Negodiuk of EVO.company, Lam Jun Rong of Calif.io, Mufeed VH of Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin of depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin of Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil), and Milan Jovic (Kljunowsky) for independently bringing this issue to our attention and following the highest standards of coordinated disclosure.
In freenginx, the accompanying information about the fix is actually limited to the commit message. In changelogThis fix isn't even labeled as "security" or "bugfix," just "feature." Apparently, the author didn't consider this issue critical. It's impossible to determine the relationship between the reported issues by the aforementioned individuals in F5 and the commit copied from freenginx, or whether they (or anyone else) reported the issue to the freenginx author.
Source: linux.org.ru
