NGINX TLS and Memory Bugs Patched in 1.30.6 and 1.31.7; F5 Issues Critical Updates
F5 releases updates for five vulnerabilities in NGINX, including critical memory bugs and a TLS flaw that may bypass client certificate checks.
Key points
- Versions 1.30.6 and 1.31.7 address five flaws, with three rated critical by F5.
- A TLS session ticket key rotation bug allows non-deterministic session forgery.
- All five vulnerabilities require specific configuration directives to be exploitable.
F5 released NGINX versions 1.30.6 and 1.31.7 on 14 October to resolve five security issues. One vulnerability has existed in every release since May 2005, while others affect specific configurations.
What happened
The update addresses three memory corruption bugs that F5 says could crash worker processes or allow code execution. Each memory flaw requires a specific configuration setup to exploit. A fourth vulnerability allows attackers to forge TLS sessions, potentially bypassing client certificate checks. F5 describes this forgery as non-deterministic and outside attacker control. The fifth flaw lets HTTP/3 clients insert extra bytes into requests passed to backends.
Why it matters
F5 scores the three memory bugs at 9.2 on CVSS v4.0, rating them critical. The TLS flaw receives an 8.3 score, while the HTTP/3 issue is rated 6.9. NGINX rates all five vulnerabilities as medium severity. None were listed in CISA’s Known Exploited Vulnerabilities catalog as of 15 October. No confirmed attacks have been reported by F5 or NGINX.
Next steps
Organisations should verify if they use the specific directives required for exploitation. These include alias with rewrite, regex maps, AIO with SSI, shared TLS session caches, or HTTP/3. Users of the shared session cache should check their key rotation mechanisms. Teams should review their NGINX versions against the fixed releases.
Detection notes
Security teams should monitor for unusual worker process crashes or restarts that may indicate memory corruption exploitation. Look for TLS session resumption anomalies, particularly where client certificates are unexpectedly bypassed or session tickets are validated with uninitialised keys. Check access logs for HTTP/3 requests containing unexpected byte sequences or malformed headers. Investigate any traffic patterns that deviate from standard TLS handshake behaviour.
Background: TLS handshake
The TLS handshake is a multi-step protocol where a client and server negotiate encryption keys and verify identities. It involves exchanging random numbers, selecting cipher suites, and performing asymmetric authentication. Understanding this process helps you identify where configuration errors allow attackers to downgrade security or intercept traffic.
Read the full guide: How the TLS Handshake Works: Mechanics, Weaknesses and Audit Points
What to do and how to stay safe: NGINX
- Review NGINX configurations for the specific directives mentioned in the advisories
- Check current NGINX versions against the fixed releases 1.30.6 and 1.31.7
- Monitor logs for TLS session anomalies and worker process crashes
- Verify that shared session cache settings are not exposing uninitialised keys
Step-by-step guide: Emergency Patching: How to Fix Critical Flaws Without Breaking Production
General security guidance from the Packet Tribune newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which NGINX versions fix these vulnerabilities?
Versions 1.30.6 and 1.31.7 address all five vulnerabilities.
Are these vulnerabilities being actively exploited?
No confirmed attacks have been reported by F5 or NGINX as of the publication date.
Do all NGINX installations need to update?
Only installations using specific configuration directives are exposed to these flaws.
