NGINX heeft recent NGINX patches uitgebracht in de versies 1.30.6 (stable) en 1.31.7 (mainline). De update verhelpt vijf kwetsbaarheden, waaronder drie geheugenproblemen die in bepaalde situaties een worker-proces kunnen laten crashen of mogelijk leiden tot code-uitvoering. Daarnaast is er een TLS-gerelateerd probleem waarmee een aanvaller een sessie zou kunnen namaken om langs client-certificate checks te glippen.
Belangrijk: F5 geeft aan dat de TLS-sessie-voorzetting niet deterministisch is en dus niet volledig onder controle van een aanvaller ligt. Toch is dit type fout relevant genoeg om snel te upgraden, zeker als je NGINX-onderdelen gebruikt die precies aan de vereiste voorwaarden voldoen.
Wat zit er in de NGINX patches?
De vijf gefixte issues hebben verschillende impact en vereisen telkens een specifieke configuratie. NGINX beoordeelt ze als medium, terwijl F5 de ernst specifieker indeelt met CVSS-scores:
- Drie geheugenbugs (crash mogelijk, of mogelijk code-uitvoering) krijgen een hoge score (CVSS v4.0: 9.2 volgens F5).
- Een TLS-bug krijgt een CVSS v4.0-score van 8.3 en kan in theorie client-certificate validatie omzeilen.
- Een HTTP/3-parserbug (met CVSS v4.0: 6.9) kan ervoor zorgen dat extra bytes als request body richting een backend worden doorgegeven.
Geen van de vijf kwetsbaarheden stond op 15 oktober in de CISA-catalogus met Known Exploited Vulnerabilities, en zowel NGINX als F5 melden geen gerapporteerde aanvallen op dat moment.
Waarom maakt configuratie het verschil?
Een terugkerend thema in deze release is dat de kwetsbaarheden niet “automatisch” misbruikt kunnen worden. Je hebt telkens een combinatie nodig van NGINX-richtlijnen en (in sommige gevallen) hoe je moduleonderdelen zijn ingericht.
NGINX noemt voor meerdere bugs dat je (o.a.) een specifieke instelling toevoegt, zoals:
- een combinatie van alias met rewrite
- een regex map met bepaalde verwerking
- AIO samen met SSI
- een shared TLS session cache zonder dat je keys correct uit een bestand laadt
- een situatie waarin HTTP/3 actief is (met voorwaarden die samenhangen met requestverwerking)
Daarnaast is een van de HTTP/3-voorwaarden volgens het bericht standaard ingeschakeld, waardoor je in de praktijk extra alert moet zijn als je HTTP/3 gebruikt.
De TLS-bug: mogelijk langs client-certificate checks
Een van de meest opvallende problemen in de NGINX patches draait om TLS session tickets. Daarmee kan een client een TLS-sessie hervatten zonder opnieuw de volledige handshake te doen. NGINX kan, afhankelijk van je setup, zelf sessiesleutels genereren en rouleren.
Volgens F5 en NGINX ontstaan er in bepaalde gevallen problemen bij die sleutelrotatie: er zou in het worker-proces een slot niet correct zijn gekopieerd bij rotatie. Hierdoor kan een ticket dat naar dat slot verwijst, worden gevalideerd en ontcijferd met “ong geïnitialiseerde” sleutel-informatie. NGINX beschrijft dat dit in theorie kan leiden tot een geforged sessie.
Met die nagemaakte sessie zou een aanvaller de verificatie van client certificates kunnen omzeilen. F5 nuanceert het wel: de werking is non-deterministisch en ligt niet volledig in de controle van de aanvaller. Toch is dit precies het type TLS-issue dat je niet wilt laten openstaan.
De door NGINX genoemde blootgestelde instelling is onder meer ssl_session_cache shared:SSL:10m (zoals in NGINX-documentatie-examples). Het bericht vermeldt ook dat NGINX in februari 2025 eerder een session-reuse fout met vergelijkbare gevolgen heeft aangepakt (met CVE-2025-23419).
Memory bugs met mogelijke RCE: drie verschillende routes
De drie geheugenproblemen die F5 beschrijft met een hoge CVSS-score vereisen elk een specifieke scenario. Dat maakt het des te belangrijker om je actuele NGINX-configuratie te vergelijken met de voorwaarden uit de advisories.
1) Regex map en een string-handling fout
De map-gerelateerde kwetsbaarheid wordt genoemd als CVE-2026-93479. Die zit in code voor het omgaan met strings, en NGINX heeft er voor deze release opnieuw een fix op gezet. Het bericht legt ook een link met eerdere wijzigingen: op 15 juli werd er al gepatcht naar aanleiding van CVE-2026-42533, een heap overflow die via regex map captures te bereiken is.
In deze nieuwe situatie ontstond de mogelijkheid opnieuw door een wijziging in dezelfde periode: bescherming tegen buffer-overrun zou weliswaar het bufferprobleem afdekken, maar toch kon data “uit lekken” naar een gereserveerd gebied. Vervolgens kon een latere patch de uiteindelijke stringgroottes zo bepalen dat die string het buffer opnieuw kon overschrijden.
De fix zet extra grenzen en beperkt de overflow tot een maximum dat samenhangt met de gereserveerde grootte op het document-root pad, of tot de grootte van een null byte op het access-log pad.
2) Alias met rewrite: een timing-window
Een andere bug is gelinkt aan een moment na een rewrite. In dat korte tijdvenster kiest NGINX nog niet de “volgende” location, maar als er iets in die periode $request_filename uitleest en de prefixlengte van de destination langer is dan de herschreven URI, kan dat bufferlogica over de schreef laten gaan.
De crux is dus: het vereist zowel de aanwezigheid van de alias-constructie als de combinatie met rewrite zoals die in jouw configuratie is opgebouwd.
3) AIO met SSI: counter wrap en vrijgeven van request memory
De derde geheugenroute is gekoppeld aan AIO (asynchronous I/O) en SSI (server-side includes). Volgens de uitleg gebruikt NGINX een 8-bit teller voor het aantal “pending asynchronous operations”. Wanneer de waarde wrapt (bij 256 pending operations), kan een request worden vrijgegeven terwijl async operations nog steeds verwijzen naar geheugen van die request.
SSI-pagina’s gebruiken include-commando’s die parallel kunnen draaien, en dat vormt het triggerpad voor deze keten.
HTTP/3: extra bytes doorgegeven aan een backend
De vijfde kwetsbaarheid gaat over HTTP/3. Hier zit de oorzaak in een parserveld dat twee taken lijkt te combineren: het bijhouden van resterende lengte bij het skippen van een onbekend frame, én het bepalen hoeveel DATA-bytes moeten worden doorgegeven als request body.
Als een onbekend frame wordt gesplitst over twee reads, kan het overgebleven “count” worden behandeld als body en worden doorgestuurd naar de backend. Daardoor zou je de checks rondom client_max_body_size kunnen omzeilen, omdat de backend alsnog requestbody-data krijgt die niet klopt met wat NGINX verwacht.
Wat moet je nu doen?
De kernactie is simpel: upgrade naar een versie die de fixes bevat.
- Upgraden naar NGINX 1.30.6 op de stable branch.
- Upgraden naar NGINX 1.31.7 op de mainline branch.
Volgens het bericht zijn deze twee releases specifiek bedoeld om fixes te bevatten. Oudere branches (zoals 1.28) vallen binnen de getroffen ranges, behalve als patches via je distributie zijn backported.
Heb je NGINX Plus of gebruik je F5-producten zoals de F5 Ingress Controller, Gateway Fabric, Instance Manager of WAF? Dan is het advies om de betreffende F5-advisories te controleren voor jouw build. Voor meerdere producten vermeldt F5 dat er tot 15 oktober nog geen fixed build beschikbaar was.
Als je niet direct kunt upgraden: check je configuratie
Kun je niet meteen upgraden, dan is de praktische stap: inventariseer welke van de blootgestelde functies bij jou actief zijn. Het bericht adviseert om je running configuratie te printen en te zoeken op specifieke patronen.
Concreet noemt het bericht om te letten op combinaties zoals:
- alias naast een rewrite
- een regex map gebruikt door root- of log_format-verwerking
- AIO samen met SSI
- listen-regels met quic (relevant voor HTTP/3)
- ssl_session_cache shared zonder dat je de ticket keys uit een file laadt
Als je merkt dat je setup precies in die categorieën valt, is dat een sterke reden om upgradeprioriteit te verhogen.
Snelle context: patchen werkt het best met prioritering
In de praktijk loont het om patchen te koppelen aan risico-indeling. Sommige teams focussen alleen op CVSS, maar deze release laat zien dat configuratie en gebruik van specifieke functies minstens zo belangrijk zijn.
Als je wilt werken met een volwassen aanpak voor het beoordelen van beveiligingsfouten en het beperken van impact, kan ook het artikel over AI-confidence is geen bewijs helpen om te waken voor schijnzekerheid bij detectie, triage en validatie. Dat gaat niet over NGINX zelf, maar wel over hoe je beslissingen neemt tijdens incidentanalyse.
Conclusie
Met NGINX patches in versie 1.30.6 en 1.31.7 worden vijf kwetsbaarheden opgelost, waaronder drie geheugenfouten met potentieel ernstige gevolgen en een TLS-probleem dat client-certificate checks kan ondermijnen onder specifieke omstandigheden. Omdat de misbruikbaarheid sterk afhangt van je configuratie, is upgraden de belangrijkste stap—en als dat niet kan, voer dan direct een gerichte configuratiecheck uit.
Heb je HTTP/3, AIO/SSI, regex maps of shared TLS session caching in gebruik? Dan is dit een moment om je NGINX-inrichting met extra aandacht te bekijken en de update zo snel mogelijk door te voeren.
Bron: https://thehackernews.com/2026/10/nginx-fixes-5-flaws-including-possible.html
