Blog · Infrastructure
NGINX in 2026
control API, njs 1.0 and five CVEs in one release
A web frontend should be boring. What changed in NGINX this year, and the five CVEs fixed in a single October release.
Where NGINX stands in 2026
Two branches coexist, as always: 1.30.x in stable and 1.31.x in mainline. As of October 30, 2026, the latest stable is nginx-1.30.6 (October 14) and mainline nginx-1.31.8 (October 21). A production with no particular reason to move stays on stable; mainline is for testing what will arrive in six months.
The three features that change operations
- La control API (mainline 1.31.5, September): reconfigure an instance
server without stopping it or rewriting a file. Across a fleet, this replaces
configuration generation followed by a
reloadwith a supervised call, with immediate rollback if the change is bad. - Les predicate locations express a condition directly in a
location declaration, instead of stacking
ifs and intermediate variables. Anyone who has maintained a 600-line configuration knows what this removes as a source of error. - Le module
ngx_http_json_moduleproduce JSON from the configuration itself, without going through a script. Useful for health endpoints and internal metrics, which until now were the pretext for a third-party module.
njs passe en version 1.0
NGINX's embedded script engine, the one that lets you write rules in JavaScript without leaving the configuration, reaches version 1.0 (1.0.1 then 1.0.2 in October). It is a symbolic milestone: the language is considered stable. That said, any embedded logic is code executed on every request: it gets tested, versioned, and limited to what cannot be done otherwise.
HTTP/3: mature, but watch it
QUIC and HTTP/3 are now production options at most hosters. The tradeoff is the same as for any young protocol: the attack surface moves. The October 14 release thus fixes an HTTP/3 request body injection (CVE-2026-95101), along with four other vulnerabilities.
The security cadence, on a timeline
| Date | Version | Fixes |
|---|---|---|
| 2026-09-02 | njs 1.0.1 | Access control bypass in js_access, crash in ngx.fetch(), memory overflow in XML canonicalization |
| 2026-09-15 | 1.30.5 / 1.31.6 | Memory overflow in the HTTP/3 module |
| 2026-10-14 | 1.30.6 / 1.31.7 | Five CVEs: alias with rewrite, expressions with variables, HTTP/3 injection, TLS session forgery, use-after-free in SSI |
| 2026-10-21 | 1.31.8 | Routine mainline |
Source: nginx.org/2026.html and the vendor's security advisories.
Five CVEs in a single release is not a sign of weakness: it is the normal rhythm of software exposed to the Internet, maintained by a small team and audited by many. What matters is the speed at which we apply, and knowing that we have applied.
What we do with NGINX in production
- A pinned version, never mainline we follow the stable of the distribution or the official repository, and we note the version in the client's file.
- Hardened TLS and HSTS protocols and suites explicitly listed, permanent redirect, security headers. A web frontend that still speaks TLS 1.0 is a problem before it is a performance.
- Rate limiting and request size
limit_req,client_max_body_size, short timeouts: three directives that prevent many incidents. - Exploitable logs a format that lets you count errors per service, not just display them. Without this, monitoring cannot say anything.
- A
reload, not arestartreloading configuration does not cut active connections; restarting the service, does.
What we do not do
We do not add unmaintained third-party modules on an exposed frontend, we do not compile NGINX by hand to gain "a few percent", and we do not let a configuration generated by a tool land in production without review. A web frontend is the entry door: it must be boring, predictable and up to date.
A similar project? We answer technical questions in a meeting, with the same figures as in these articles.
The matching service: cybersecurity auditing and Stormshield firewalls.