Originally published at https://monstermegs.com/blog/nginx-security-update/
Two days ago the NGINX project shipped a pair of releases at once, and the quieter half is the one worth your attention. Alongside nginx 1.31.5, the team published njs 1.0.1, which closes three separate vulnerabilities in the JavaScript engine that thousands of servers use to make routing and access decisions. One of them lets a request slip past an access rule an administrator believed was being enforced. If your site sits behind NGINX, or behind a CDN, load balancer, or reverse proxy that runs it, this NGINX security update is one to apply rather than queue.
What Shipped in the September NGINX Security Update
The release landed on September 2, 2026. On the mainline side, nginx 1.31.5 is a feature release: it introduces a Control API, predicate locations, and a new ngx_http_json_module. Those are meaningful additions for anyone building dynamic configuration or handling JSON at the edge, and they are the headline most coverage led with.
The njs 1.0.1 release published the same day is where the security content lives. It patches CVE-2026-18329, an access control bypass in js_access; CVE-2026-78222, a worker process crash triggered through ngx.fetch(); and CVE-2026-78689, a heap buffer overflow in xml.exclusiveC14n(). All three are documented in the project's own 2026 release notes. Bundling a feature release and a security release in the same announcement is normal practice for the project, but it does mean the NGINX security update can get lost behind the shinier feature list.
The Three njs Flaws Behind the NGINX Security Update
njs is NGINX's scripting engine. It is optional, but it is widely deployed in front of APIs and applications precisely because it lets operators write logic that plain configuration directives cannot express. That includes authorization checks, which is what makes the first flaw in this NGINX security update more serious than a version bump suggests.
The js_access bypass
js_access exists so operators can write their own access decisions in JavaScript and have NGINX enforce the verdict. CVE-2026-18329 is an access control bypass in that mechanism. The practical risk is straightforward: a check that returns “deny” in testing may not deny in every code path, and nothing in your logs necessarily screams that it failed. Configurations that use js_access as the only gate in front of an internal endpoint carry the most exposure here.
The ngx_fetch crash
CVE-2026-78222 crashes a worker process through ngx.fetch(), the function njs scripts use to call out to other services. A crashed worker is not a breach, but repeated crashes are a denial of service, and ngx.fetch() had already been hardened once this year in njs 1.0.0 back in June. Seeing it patched twice in three months is a signal about where the fragile surface sits.
The XML canonicalization overflow
CVE-2026-78689 is a heap buffer overflow in xml.exclusiveC14n(), the XML canonicalization helper used mostly in SAML and signed-document workflows. Heap overflows in a worker process are the category that occasionally graduates from crash to code execution, which is why this part of the NGINX security update deserves priority even though the affected function is niche.
The njs Engine Change That Set the Stage
These fixes did not appear in a vacuum. In June 2026, njs 1.0.0 marked a genuine turning point for the scripting layer: the project deprecated its original njs engine in favor of QuickJS, aligned exception classes across both engines, and hardened ngx.fetch() request validation. That was a major-version milestone, and major-version milestones move a lot of code at once.
Two of the three flaws in the September NGINX security update sit in areas that release touched. That is not a knock on the migration, which brings a faster and better-tested JavaScript engine to a component that badly needed one. It is a reminder of how transitions behave in practice: the months immediately after a large refactor are when researchers find the most, and when operators need to track releases most closely. Anyone who adopted njs 1.0.0 early should treat this NGINX security update as part of the same story rather than an isolated patch.
This NGINX Security Update Fits a Busy 2026 Pattern
Read the 2026 changelog end to end and a rhythm emerges. February closed an SSL upstream injection issue. March fixed buffer overflows in the DAV and MP4 modules plus two mail session authentication flaws. May brought a six-CVE release covering HTTP/2 request injection, HTTP/3 address spoofing, and a use-after-free in OCSP resolver requests. June and July each added three more. This NGINX security update is not an outlier; it is the eighth batch of fixes in nine months.
That cadence is not a sign of a project in trouble. It is what a mature, heavily audited codebase looks like when researchers are actively pointing tools at it. The problem is on the operator side: patch fatigue is real, and a server that is three NGINX security update cycles behind is running known, published, exploitable code.
The July Flaw That Should Change How You Read These Notes
The clearest argument for taking each NGINX security update seriously arrived in July. CVE-2026-42533, patched in nginx 1.30.4 and 1.31.3, is a heap buffer overflow in the map directive's regex handling that carries a CVSS v4.0 score of 9.2. It affects a range of versions stretching back to 0.9.6, and it is reachable pre-authentication through crafted HTTP requests.
What makes it instructive is that it is configuration-dependent. The dangerous pattern involves regex-based map directives using numbered captures such as $1 or $2, with a string expression referencing the map output after an earlier regex match. Plenty of servers running affected versions were never exploitable. Plenty of others were, and had no way to know without reading their own configuration line by line. That is the trap: version numbers alone do not tell you your exposure, and skipping an NGINX security update because “we probably do not use that module” is a guess dressed up as a decision.
Why This Reaches Far Beyond People Who Run NGINX
As of September 4, 2026, W3Techs measures NGINX at 31.3% of all websites whose web server is known, ahead of Cloudflare Server at 29.9%, Apache at 22.5%, and LiteSpeed at 14.7%. That makes it the single most common web server on the public internet.
More to the point, NGINX is rarely the only thing in the path. It sits inside CDN edge nodes, Kubernetes ingress controllers, API gateways, and the reverse proxy layer of hosting stacks that terminate on something else entirely. A site owner who has never typed an nginx command may still depend on half a dozen NGINX instances between a visitor and their content. When an NGINX security update ships, the relevant question is not “do I run NGINX” but “who in my delivery chain does, and have they patched?”
That question has teeth. We have already seen this year how quickly attackers industrialize access to compromised web servers, and unpatched proxy layers are exactly the kind of quiet foothold that gets recycled into larger campaigns.
What Site Owners Should Do After This NGINX Security Update
If you administer your own servers, the direct action is to move to njs 1.0.1 and, if you track mainline, nginx 1.31.5. Then audit specifically for the exposed surface: grep your configuration for js_access, ngx.fetch(), and any njs code touching XML canonicalization, and treat those blocks as suspect until the update is in place. While you are in there, check for the regex map pattern behind CVE-2026-42533 as well.
If someone else runs your stack, this NGINX security update turns into a support question rather than a shell session. Ask your host or CDN provider which nginx and njs builds they are running and when the September patches land. A provider who can answer that in one reply is telling you something useful about how they operate. On managed platforms the patching should already be handled for you, which is the practical case for LiteSpeed NVMe hosting where the server layer is somebody else's job. It is the same dynamic we covered when the LiteSpeed server update added post-quantum encryption earlier this year: the value of a managed stack is that these releases reach your sites without you scheduling a maintenance window.
Either way, do not treat “we are on a supported version” as the finish line. Supported and patched are different states, and the gap between them is where most real incidents start.
The Takeaway
Three things are worth carrying away from this release. First, the September NGINX security update patches a genuine access control bypass, not just crash bugs, so the js_access flaw deserves same-week attention. Second, 2026 has produced a steady stream of NGINX fixes, and falling behind by even a few cycles now means running publicly documented vulnerabilities. Third, because NGINX runs somewhere in almost every delivery chain, this NGINX security update is worth asking about even if you have never configured a web server yourself.
If keeping up with releases like this is not how you want to spend your week, MonsterMegs handles the server layer on every managed WordPress hosting plan so patches land without a ticket from you.
Top comments (0)