NGINX Fixes Need a Configuration Check, Too
Three NGINX memory-safety flaws need a configuration check as well as a version check. They affect HTTP request processing, so restricting access to a management interface does not remove the relevant request paths. F5 describes unauthenticated attacks, with particular configurations and additional conditions determining the outcome.
The vendor’s public vulnerability records were published on 14 October. For all three issues, the official NGINX Open Source advisory list identifies 1.30.6 and 1.31.7 as corrected releases in their respective branches. NGINX Plus and software that bundles NGINX need their own supported product update.
Three routes into a worker process
CVE-2026-15176 concerns a location that combines alias and rewrite with a set or return expression referencing $request_filename. Referencing that variable in an access-log format provides an alternative route. Crafted requests can trigger a heap buffer overflow and restart the worker. The presence of a file-serving location alone does not establish that the required combination exists.
CVE-2026-93479 concerns evaluation order around a regex map. F5 describes a root directive or access-log format that references the map’s regex capture values before the map output. Certain uses of a non-cacheable variable in a string expression can produce the same result. Finding a map directive is therefore a starting point for review, not proof of exposure.
CVE-2026-97205 combines asynchronous file I/O with certain server-side include configurations. Processing an SSI page containing include virtual commands can trigger use after free, memory corruption or a worker crash. Inventory whether those features are actually in use rather than assuming that every reverse proxy serves SSI content.
A crash and code execution are different outcomes
F5 says code execution additionally depends on Address Space Layout Randomization being disabled or an attacker being able to bypass it. Preserve that condition when assessing the risk. A worker restart is a potential denial of service; it is not evidence that an attacker has executed code. Equally, ASLR being enabled does not establish that every possible bypass is absent.
The severity labels also need their context. NGINX’s own list labels these three entries medium. F5’s records assign each a CVSS 3.1 score of 8.1, High, and a CVSS 4.0 score of 9.2, Critical. These are different rating schemes, not three interchangeable descriptions of the exposure of a particular server. The records examined here do not establish that a particular organisation has been compromised.
Use the right correction for the installed product
For upstream Open Source installations, match the installed branch to the corrected release and use a maintained package. A distribution may backport a correction under its own package revision, so consult its actual security notice. Do not infer that a commercial appliance or bundled application is fixed merely because its component name is NGINX.
F5’s NGINX Plus records distinguish the 37.1 and 37.0 maintenance lines from R33 through R36. They record affected 37.1.0 builds below 37.1.0.1 and 37.0.0 builds below 37.0.5.1, while the older listed release lines do not gain a universal fixed build from that data. Check the applicable F5 advisory and supported upgrade path for the actual product. F5 also explicitly says versions beyond End of Technical Support were not evaluated.
There is a scope difference worth preserving for the asynchronous-I/O issue. The upstream advisory list traces its vulnerable Open Source history back to 0.8.11, whereas F5’s structured CVE entry lists affected ranges starting at 1.30.0 and 1.31.0. A shorter structured range should not be used to clear an older installation that the upstream list identifies as vulnerable.
Interim changes need their own verification
Where an immediate update cannot be completed, F5 publishes issue-specific mitigations. For the alias problem, it advises avoiding alias in a location and avoiding the filename variable. For the map problem, it recommends named captures instead of unnamed captures and limiting their use to the block containing the regex match. For the SSI problem, its alternatives are disabling asynchronous file I/O or not serving SSI pages.
Those are targeted changes, not a general instruction to remove every map or rewrite directive. Review their effect on the application in an authorised maintenance process, preserve a recovery configuration and verify the relevant request paths after the change. Keep ASLR and certificate validation protections enabled.
After maintenance, confirm the running package or product build on each serving instance, including standby systems and containers. Record which vulnerable feature combinations were present, which correction or interim mitigation was applied and what remains unresolved. Investigate suspicious earlier worker crashes separately from the update receipt. A completed upgrade demonstrates a maintenance action, not the absence of earlier misuse.
Source reporting: F5’s current CVE Program records for the alias issue, the map issue and the asynchronous-I/O issue, together with the official NGINX advisory list linked above. Descriptions and version scopes were checked on 1 November.
