NGINX fixes zijn er in twee nieuwe releases: 1.30.6 (stable) en 1.31.7 (mainline). De updates lossen samen vijf kwetsbaarheden op, waaronder drie geheugengerelateerde bugs die een worker-proces kunnen doen crashen en in bepaalde situaties mogelijk code-uitvoering op afstand mogelijk maken. Daarnaast is er een TLS-gerelateerde fout die client-certificate checks kan omzeilen, en een probleem in HTTP/3 waarbij extra bytes uit een request kunnen worden doorgegeven aan een backend.
F5, de beheerder achter NGINX, meldt geen actieve aanvallen en geen opname in de CISA Known Exploited Vulnerabilities-catalogus (stand van 15 oktober). Toch is dit precies zo’n update waar je snel naar moet kijken: de kwetsbaarheden hebben allemaal specifieke configuratievoorwaarden, en die kun je in veel omgevingen al “per ongeluk” tegenkomen.
Wat er is opgelost in de NGINX fixes
NGINX brengt met de NGINX fixes in 1.30.6/1.31.7 vijf beveiligingsproblemen in één keer samen. De ernst varieert, maar F5 beoordeelt de drie geheugengerelateerde issues als kritiek (CVSS v4.0 9.2) en rekent de TLS-bug op 8.3. De HTTP/3-kwetsbaarheid krijgt 6.9. NGINX zelf labelt alles als medium.
1) Drie geheugenbugs: crash of mogelijk RCE
De drie geheugenproblemen vereisen elk een andere instelling in je NGINX-configuratie om te kunnen worden misbruikt. F5 geeft aan dat een succesvolle aanval óók afhankelijk is van die specifieke voorwaarden. Wat voor jou als beheerder vooral belangrijk is: als je een van die opties gebruikt, is de kans dat je geraakt kunt worden niet “hypothetisch”.
2) TLS bug: mogelijk client-certificate checks omzeilen
De vierde kwetsbaarheid gaat over het verwerken van TLS-sessies. F5 noemt het “non-deterministic” en zegt dat een aanvaller er niet volledig de hand op kan leggen. Maar het effect kan wél groot zijn: een aanvaller zou een gesimuleerde TLS-sessie kunnen opbouwen waardoor verificatie van clientcertificaten wordt omzeild.
Het gaat in de kern om de manier waarop NGINX TLS sessie-tickets beheert wanneer je een shared session cache gebruikt.
3) HTTP/3: extra bytes in request doorgeven
De vijfde bug is gekoppeld aan HTTP/3. Daarbij kan een HTTP/3-client ongewenste extra bytes in een request “slippen”, waarna NGINX die bytes doorgeeft aan een backend. Omdat de doorvertaling afhangt van hoe de request wordt geparsed en gesplitst, is misbruik ook hier niet willekeurig, maar wel relevant voor omgevingen die HTTP/3 inzetten.
Welke configuraties de risico’s bepalen
Een terugkerend patroon in deze NGINX fixes: je wordt niet automatisch kwetsbaar. In plaats daarvan moet je server een combinatie van codepad en specifieke richtlijnen bevatten.
NGINX en F5 noemen (samengevat) de volgende voorwaarden die je moet controleren in je draaitafel:
- alias met rewrite, met een overflow die optreedt in de overgang tussen URI-verandering en locatie-resolutie
- regex map (met name string/handling gerelateerd aan captures), waarbij de kwetsbaarheid in string-afhandeling zit
- AIO in combinatie met SSI, waarbij parallelle include-requests een teller-exploit mogelijk maken
- shared TLS session cache (zonder de manier waarop keys uit een bestand worden geladen)
- HTTP/3, waarbij een parser-veld twee functies combineert en split reads tot doorgeven van bytes leiden
De TLS-fout nader bekeken: waarom client-certs kunnen worden geraakt
De TLS-kwetsbaarheid draait om session ticket keys en de rotatie daarvan. Session tickets maken het mogelijk om een TLS-sessie te hervatten zonder een volledige handshake. Vanaf NGINX-versie 1.23.2 genereert NGINX volgens F5/NGINX de ticket keys zelf als je niet expliciet keys uit een bestand laadt.
Elke worker heeft kopieën van meerdere “key slots”. Bij rotatie werden slechts twee slots gekopieerd, terwijl de derde slot een eerder in-memory item kon bevatten. In het scenario dat de fix adresseert, kan een ticket die een specifieke slotnaam gebruikt daardoor worden geverifieerd en gedecrypte met onbedoeld materiaal. Dat zou vervolgens de deur kunnen openen voor het bypassen van client-certificate verificatie.
F5 noemt als voorbeeld van een relevante instelling ssl_session_cache shared:SSL:10m, zoals terug te vinden is in NGINX’s eigen documentatievoorbeelden.
De memory bug die teruggrijpt op eerdere reparaties
Een van de meest opvallende details is dat één bug doorloopt in code die eerder al is aangepast. De kwetsbaarheid rond de map (CVE-2026-93479) is gekoppeld aan string-handling. NGINX had eerder op 15 juli al gepatcht voor een gerelateerde issue (CVE-2026-42533) waarbij F5 9.2 als score gaf. Volgens het fix-commit ontstond de nieuwe overflow juist door een latere wijziging: eerst werd bescherming toegevoegd tegen het overschrijden van een buffergrens, maar daarna bleek er nog ruimte voor data die in een gereserveerd gebied kon “overlopen”. Een daaropvolgende wijziging bepaalde vervolgens de string-grootte op basis van die overlooplengte, waardoor de string weer buiten de buffer kon komen.
In de uiteindelijke fix heeft de wijziging beperkingen ingebouwd (o.a. gekoppeld aan groottes op paden en een nul-byte scenario voor logpaden).
Wat je nu moet doen (praktische aanpak)
De aanbeveling is eenvoudig: upgrade. F5 en NGINX adviseren:
- Upgrade naar 1.30.6 op de stable branch, of
- Upgrade naar 1.31.7 op de mainline branch.
NGINX levert de fixes alleen uit voor deze twee branches. Oudere releases blijven daardoor in het risicogebied vallen. Ook geldt: als je distributie patches heeft teruggeporteerd, ben je mogelijk al beschermd—maar dan moet je dat wel verifiëren in de release notes of changelog van jouw pakketbeheer.
Als je niet meteen kunt upgraden: controleer je config
Kun je nog niet naar een vaste release? Dan is de volgende stap het gericht opsporen van de instellingen die tot exploitvoorwaarden leiden. Je kunt je werkconfiguratie afdrukken met nginx -T en daarna doorzoeken op patronen rondom:
- alias samen met een rewrite
- een regex map die voor root of loggerelateerde verwerking wordt gebruikt
- aio gecombineerd met ssi
- HTTP/3-instellingen (quic/listen)
- ssl_session_cache “shared” zonder de manier waarop ticket keys uit een bestand komen
Zo kun je bepalen of je jezelf in een kwetsbaar codepad hebt gezet. Let op: de juiste trigger is precies wat dit soort bugs gevaarlijk maakt—zonder die trigger is de kwetsbaarheid niet (relevant) exploiteerbaar.
NGINX Plus en F5-producten
Als je NGINX Plus gebruikt, of F5’s Ingress Controller, Gateway Fabric, Instance Manager of WAF inzet, dan moet je de bijbehorende F5-advisories nalopen. In sommige gevallen (zoals F5 aangeeft) is er mogelijk nog geen fixed build beschikbaar per 15 oktober.
Gerelateerd: waarom patchen prioriteit heeft
Deze update laat opnieuw zien hoe kwetsbaarheden in webservers snel waarde kunnen krijgen zodra de juiste omstandigheden bestaan. Daarom loont het om je patchproces te koppelen aan concrete configuratie-inventarisatie. Als je meerdere lagen hebt (proxy’s, reverse proxies, ingress, TLS-instellingen), is “we hebben bijgewerkt” niet genoeg—je moet ook weten wat je draait.
Ter inspiratie voor een aanpak met verificatie en validation kun je ook lezen hoe je misverstanden rond AI-confidence in assessments voorkomt: AI-confidence is geen bewijs: zo voorkom je fouten.
Conclusie
Met de NGINX fixes in versies 1.30.6 en 1.31.7 pak je vijf beveiligingsproblemen aan, waaronder geheugenbugs die een worker kunnen laten crashen en mogelijk RCE mogelijk maken onder specifieke configuraties. Daarnaast wordt een TLS-bug opgelost die in theorie client-certificate checks kan omzeilen via geslaagde sessieconstructie, en is er een HTTP/3-issue die extra request-bytes kan doorgeven aan een backend.
De beste stap is direct upgraden. Lukt dat (nog) niet? Controleer dan met nginx -T of je één van de relevante triggers gebruikt—want juist die instellingen bepalen of de theoretische kwetsbaarheid in jouw omgeving een praktisch risico wordt.
Bron: https://thehackernews.com/2026/10/nginx-fixes-5-flaws-including-possible.html
3 reacties