NGINX heeft NGINX fix vijf kwetsbaarheden doorgevoerd met releases 1.30.6 (stable) en 1.31.7 (mainline). Onder de verbeteringen zitten geheugen-gerelateerde bugs die in bepaalde scenario’s kunnen leiden tot crashes en mogelijk tot code-uitvoering, plus een TLS-kwetsbaarheid die client-certificate checks kan omzeilen. Hoewel er volgens F5 en NGINX geen actieve aanvallen zijn gemeld, is upgraden verstandig.
De update komt op 14 oktober en is relevant voor iedereen die NGINX gebruikt in productie—zeker als je specifieke modules, configuratie-instellingen of HTTP/3 hebt ingeschakeld.
Wat er precies is opgelost
In de nieuwe versies worden vijf kwetsbaarheden gepatcht. NGINX en F5 classificeren ze allemaal als “medium”, maar de details verschillen sterk. De drie geheugenproblemen kunnen volgens F5 een worker-proces laten crashen of mogelijk code laten draaien—mits je een specifieke configuratie gebruikt.
Daarnaast is er een vierde bug waarmee een aanvaller een TLS-sessie kan vervalsen. F5 benadrukt dat dit “niet-deterministisch” is en buiten de controle van de aanvaller ligt, maar het kan wel leiden tot het voorbijgaan aan verificatie van client-certificaten.
Tot slot is er een vijfde kwetsbaarheid in de manier waarop NGINX met HTTP/3 omgaat: een HTTP/3-client kan extra bytes in een request laten “meelopen” naar een backend.
Waarom configuratie allesbepalend is
Het opvallende aan deze NGINX fix vijf kwetsbaarheden is dat niet iedereen automatisch risico loopt. Voor elk van de vijf bugs geldt dat er een specifieke directive of combinatie van instellingen nodig is.
In grote lijnen komt het neer op het volgende: je moet bijvoorbeeld werken met een alias in combinatie met een rewrite, een regex-map gebruiken op een manier die raakt aan de kwetsbare code, AIO in combinatie met SSI inschakelen, een shared TLS-session cache gebruiken zonder de juiste sleutelset, of HTTP/3 actief hebben.
NGINX’s eigen documentatie raadt volgens de advisories met name aan om een shared session cache en request buffering te gebruiken, maar juist die TLS-session cache speelt ook een rol bij de TLS-bug—waardoor je dus extra kritisch moet zijn op hoe je dit geconfigureerd hebt.
De TLS-bug: client-certificate checks omzeilen
De TLS-kwetsbaarheid draait om session ticket keys en hoe NGINX die roteert. Session tickets maken het mogelijk om een TLS-sessie te hervatten zonder een volledige handshake. Sinds versie 1.23.2 (oktober 2022) kan NGINX ticket keys zelf genereren en roteren wanneer je een shared session cache gebruikt, tenzij je de keys vanuit een bestand laadt.
Volgens F5 blijft bij worker-processen een kopie van drie sleutel-slots beschikbaar. Bij de rotatie worden er echter slechts twee slots gekopieerd. Daardoor kan een derde slot “restdata” bevatten uit het geheugen van vóór die rotatie. Als een ticket dat slot aanwijst, kan het daarmee worden gevalideerd en ontsleuteld met een niet-geïnitialiseerde sleutel, wat F5 beschrijft als het mogelijk toestaan van een vervalste sessie.
De concrete blootstellingssetting die F5 noemt is: ssl_session_cache shared:SSL:10m. NGINX verwijst voor de herstelaanpak naar de nieuwe release.
Een vergelijkbaar type probleem zat eerder ook in dezelfde categorie (met gevolgen voor session reuse), dat in februari 2025 is gefixt met de publicatie rond CVE-2025-23419.
Drie geheugenbugs met verschillende triggers
Naast de TLS-bug zijn er drie geheugen-gerelateerde kwetsbaarheden die in theorie zowel crash als mogelijke code-uitvoering kunnen veroorzaken. Bij elk van deze issues is een specifieke configuratie-combinatie nodig.
1) Alias + rewrite: overflow in de URI→pad mapping
Deze bug activeert in een smal venster: nadat een rewrite de URI wijzigt en voordat NGINX de volgende location selecteert. Als in dat korte tijdsgebied iets $request_filename uitleest, en de prefix van de gekozen location langer is dan de gerewrite URI, dan kan de mapping van URI naar een bestandspad een buffer-overflow veroorzaken.
2) AIO + SSI: teller kan omklappen
De tweede geheugenbug komt door een counter voor asynchrone operaties. Elke pending async operatie telt op in een 8-bit veld zonder controle. Daardoor kan het veld na 256 pending operaties omklappen naar nul. Als gevolg kan de request memory vrijgegeven worden terwijl die async operaties nog naar hetzelfde geheugen verwijzen.
In NGINX’s beschrijving is SSI een belangrijke trigger, omdat SSI-pagina’s include-requests in parallel kunnen uitvoeren.
3) HTTP/3 parser: extra bytes buiten checks
De derde geheugenbug zit in de HTTP/3 parserlogica. Een parser-veld krijgt twee rollen: het bewaart resterende lengte van een frame dat wordt overgeslagen, én het aantal DATA bytes dat doorgestuurd moet worden als request body. Wanneer een onbekend frame gesplitst wordt over twee reads, wordt het resterende tellerveld behandeld als body-lengte en gaat het mee naar de backend—buiten de reguliere client_max_body_size check.
De map/regex bug: link met eerdere patches
De bug met betrekking tot string-handling en regex maps (CVE-2026-93479) hangt volgens de fix-commit samen met wijzigingen die eerder in juli zijn doorgevoerd. NGINX zou in juli al bescherming hebben toegevoegd tegen het overschrijven voorbij een buffer, maar data kon alsnog in een gereserveerd gebied terechtkomen. Daarna werd de uiteindelijke stringlengte bepaald op basis van de uitgespaarde lengte, waardoor een string toch kon doorgroeien buiten de buffer.
De commit zet daar nu limieten aan: de overflow blijft volgens de beschrijving maximaal gelijk aan de grootte van het gereserveerde gebied op de document-root pad, of—bij het access-log pad—beperkt met een null-byte.
Een extra nuance: onderzoekers en eerdere feedback gaven aan dat een workaround via named captures de aanvalsroutes niet volledig sluit. “Upgraden” blijft dus de complete oplossing.
Wat je vandaag moet doen
Het advies is helder: upgrade naar NGINX 1.30.6 (stable) of 1.31.7 (mainline). Stable bevat alleen fixes, dus dit is doorgaans de meest directe route.
Controleer ook of je distributie of pakketbeheer backports heeft gedaan. Als je op oudere branches of builds draait (bijvoorbeeld 1.28), val je mogelijk nog steeds binnen de getroffen ranges.
Als je niet direct kunt upgraden: check je blootstelling
Kun je (nog) niet upgraden? Dan is de volgende stap: breng je actuele configuratie in kaart. NGINX zelf geeft als praktische manier om de running configuration te printen en vervolgens te zoeken naar de relevante instellingen.
Zoek in je nginx -T output op combinaties zoals: alias naast rewrite, een regex map gebruikt bij root of log_format, AIO samen met SSI, listen-regels met quic (HTTP/3), en ssl_session_cache shared in combinatie met het ontbreken van ssl_session_ticket_key.
Dat helpt je om te bepalen of jouw setup überhaupt aan de voorwaarden voldoet. Let op: de advisories noemen ook dat je distributie de patches pas heeft als die daadwerkelijk is verwerkt.
NGINX Plus en F5-producten: kijk naar specifieke advisories
Gebruikers van NGINX Plus en van F5-oplossingen zoals de Ingress Controller, Gateway Fabric, Instance Manager en WAF moeten volgens de bron ook de advisories van F5 raadplegen. Voor sommige producten bestond er op 15 oktober nog geen vaste build, waardoor je plan van aanpak mogelijk afwijkt van “alleen upgraden”.
Extra: NGINX njs module kreeg ook fixes
Op dezelfde dag verscheen ook njs 1.0.2, met fixes voor twee medium-severity kwetsbaarheden in de XML-handling van de JavaScript-module (CVE-2026-101025 en CVE-2026-101019). Als je NGINX uitbreidt met njs, loont het om die componenten mee te nemen in je patchronde.
Vergelijkbare aanpak: test je veiligheidsverificaties en chain-of-trust
Deze update laat opnieuw zien dat webserver-beveiliging vaak draait om de interactie tussen configuratie, sessie-afhandeling en requestverwerking. Wil je daarnaast je verdedigingslaag testen op basis van wat je echt valideert (en niet alleen op “bewijs” dat te manipuleren is)? Dan kan dit artikel helpen: AI confidence is geen validatie: zorg voor bewijs in je DFIR-aanpak.
En werk je met beveiliging rond OT of omgevingen waar wijzigingen extra impact kunnen hebben, dan is het nuttig om procedures voor veilige testen en uitrol te hebben—zie bijvoorbeeld AI-agenten in OT in minuten testen: zo doe je het veilig.
Conclusie
Met NGINX fix vijf kwetsbaarheden in 1.30.6 en 1.31.7 pakt NGINX meerdere risico’s tegelijk aan: geheugenproblemen met mogelijke crash of RCE, een TLS-issue die client-certificate checks kan omzeilen, en een HTTP/3 parserbug. Omdat elke kwetsbaarheid specifieke configuratievoorwaarden heeft, is het extra belangrijk om je instellingen te verifiëren—maar de veiligste route blijft: upgraden.
Pak daarom deze release direct op in je patchplan, controleer daarnaast ook NGINX Plus/F5-afhankelijkheden en neem de njs update mee als je die gebruikt. Zo verklein je de kans dat je server in een kwetsbaar spoor terechtkomt.
Bron: https://thehackernews.com/2026/10/nginx-fixes-5-flaws-including-possible.html
