TL;DR: Facing the third buffer overflow discovered in 2026 (and, according to F5, RCE if ASLR is not present) when working with regex and variables, freenginx developer Maxim Dunin decided it was time to put an end to this and added a size check for the variable before writing data into it. This innovation was then borrowed by nginx, raising hopes for the cessation of new CVEs on this topic.
Now for the details.
On June 19, a change was made the commit in freenginx, adding an 'end' field to the variable descriptor indicating the end of the buffer. Previously, there was only a pointer to its start (pos), and the required length was calculated (and still is) in advance, assuming that the correctly calculated length would guarantee that the data would fit into the buffer at the moment of copying into the variable. Unfortunately, twice in May 2026, due to various oversights, this turned out not to be the case (1 (linux.org.ru), 2 (linux.org.ru)), which led to buffer overflows and negative consequences. So now, when creating a buffer for a variable, a pointer to its end is also filled, and before writing data into the variable, if the data does not fit, the request processing will be deliberately concluded with an error. This means that length calculation errors may still exist, but they will now fail only the specific HTTP request instead of crashing the memory. Subsequent commits (2 (freenginx.org), 3 (freenginx.org)) added similar protection in other parts of the code, including the access log management code. On July 7, version freenginx 1.31.3, including this fix, was released.
On July 15, these commits were adopted by nginx (1 (github.com), 2 (github.com), 3 (github.com), for some reason swapping the second and third in the chain), the issue was assigned a CVE-2026-42533, and F5 released an official SA (f5.com).
Regarding the specific vulnerability this time: it occurs when using the map directive with regexes that capture parameters. As for the other necessary conditions for it to trigger, the text in the commit description and in the SA differ slightly: the SA states that there should be a calculation of a certain string using the captured parameter left from the map before the result of that same map. In the commit description, the example includes resetting a variable that contains the captured parameter between these steps. Nevertheless, most running nginx instances are unlikely to encounter this, so the vulnerability has affected very few people. It's also worth noting that corrections for length calculations specifically in this case seem to be absent in the committed changes (or maybe I didn't search well enough?); there is only a safeguard that turns the problem into a controlled failure of the HTTP request. However, on July 19, some corrections were added in freenginx.5bfb, 7622, b906) for length calculations in a similar situation, but it's not immediately clear if it's related or not.
The vulnerability appeared in nginx version 0.9.6, with fixes included in freenginx versions 1.31.3, nginx 1.30.4, nginx 1.31.3.
In the SA, nginx acknowledges several individuals for their independent vulnerability reports and adherence to 'standards of coordinated disclosure':
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, 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.https://vexera.ai),
In freenginx, the accompanying information about the fix is essentially limited to the commit message. In this case, the fix isn't even marked with a 'security' or 'bugfix' label, but simply as a 'feature.' It's likely the author did not consider this issue critical. I could not determine how the reports of the problem from the mentioned individuals in F5 correlate with the commit borrowed from freenginx, and whether they (or anyone else) alerted the author of freenginx about the problem. changelogThe language model with 28.9 million parameters was successfully implemented on the ESP32-S3.
Source: linux.org.ru
