Apache HTTP Server heeft een kritieke kwetsbaarheid in de HTTP/2-module mod_http2 naar buiten gebracht. Met de aanduiding CVE-2026-119618 kan een aanvaller die het systeem kan bereiken, Apache HTTP/2 RCE uitvoeren: het op afstand uitvoeren van code op de server, zonder dat authenticatie nodig is.
De impact is groot omdat het gaat om Remote Code Execution (RCE) en de ernst op de CVSS-schaal door de leverancier hoog wordt ingeschat. In dit artikel lees je wat er precies aan de hand is, welke versies kwetsbaar zijn en welke stappen je nu het beste zet.
Wat is er kwetsbaar aan mod_http2?
De fout zit in de HTTP/2 module van Apache HTTP Server: mod_http2. Als de module actief is en HTTP/2 is ingeschakeld, kan een externe aanvaller misbruik maken om code uit te voeren op de server.
Volgens de publicatie is de kwetsbaarheid CVE-2026-119618 en levert die het vermogen om het proces van de server volledig onder controle te krijgen. Dat maakt dit niet alleen een crash- of informatielek, maar een route richting volledige systeemcontrole.
Welke Apache versies lopen risico?
De kwetsbare Apache HTTP Server-releases lopen van 2.4.55 tot en met 2.4.70. De fix zit in 2.4.71, die (volgens het bericht) recent is uitgebracht.
Daarnaast geldt er ook een aandachtspunt voor standalone builds van de module. Het project mod_h2 (een los pakket op GitHub) is kwetsbaar in versies 2.0.8 tot en met 2.0.42. Als je met zulke standalone varianten draait, moet je dezelfde logica toepassen: updaten zodra er een fix beschikbaar is, of de betreffende HTTP/2-onderdelen verwijderen/uitschakelen waar dat in jouw omgeving kan.
Wanneer is je server echt kwetsbaar?
Niet elke Apache server is automatisch getroffen. Alleen servers waarop HTTP/2 daadwerkelijk is ingeschakeld, vallen onder het risicoprofiel.
HTTP/2 wordt in Apache geactiveerd via de Protocols-richtlijn. Die kan je instellen:
- voor de hele server (serverbrede configuratie), of
- per virtual host.
In de documentatie worden daarbij twee varianten genoemd: h2 voor HTTP/2 over TLS en h2c voor HTTP/2 over plain TCP. De kern is dus: controleer zowel de serverbrede instellingen als elke afzonderlijke virtual host waar HTTP/2 is geconfigureerd.
Is er al misbruik in het wild?
De publicatie meldt dat een vendor-rapport (Red Hat) stelt dat public research een betrouwbare exploit heeft aangetoond voor een server in standaardconfiguratie met mod_http2 ingeschakeld. In het bericht wordt die research niet concreet genoemd of gelinkt.
Daarna gaf beveiligingsbedrijf Wiz aan dat er op dat moment geen exploit beschikbaar zou zijn en dat er geen uitbuiting in het wild was gemeld. Dat gezegd hebbende: omdat het om RCE gaat en de kwetsbaarheid tot een volledig compromis kan leiden, is het risico in de praktijk vooral een kwestie van tijd en exposure. Werk daarom alsof de fout actief kan worden misbruikt zodra HTTP/2 beschikbaar is.
Wat moet je nu doen?
Er zijn grofweg twee sporen: updaten of HTTP/2 uitschakelen als je niet direct kunt patchen.
1) Update naar de vaste Apache-versie
Als je de Apache HTTP Server-projectreleases gebruikt, ga dan naar 2.4.71 of later. Die versie bevat de fix voor CVE-2026-119618.
Gebruik je een distributie (bijvoorbeeld een Linux-variant van een vendor), dan levert die vaak een eigen gepatchte pakketversie. In het bericht staat dat Red Hat de fix voor verschillende releases heeft geleverd en de ernst voor sommige eigen releases anders labelt, mede door verpakking/architectuurverschillen. Check daarom altijd je eigen pakketversie en releasekanalen.
2) Geen update mogelijk? Pas Protocols aan
Als je nog niet kunt patchen, noemt de advisory (zoals beschreven in het bericht) geen directe “workaround” in de vorm van een veilige instelling binnen mod_http2. Wel wordt geadviseerd om h2 en h2c te verwijderen uit de Protocols-richtlijn en terug te vallen op http/1.1.
Praktisch betekent dit: haal HTTP/2 uit je configuratie voor zowel de serverbrede context als elke relevante virtual host. Zo verklein je de kans dat mod_http2 nog aangesproken kan worden via HTTP/2-traffiek.
Let ook op aanvullende modulefouten
De fixversie 2.4.71 pakt volgens de publicatie niet alleen CVE-2026-119618 aan. In dezelfde release wordt ook een crash in mod_md gerepareerd (geclassificeerd als belangrijk) en een one-byte overwrite in mod_vhost_alias (laag geclassificeerd).
Voor veel organisaties is dat een extra argument om meteen naar de meest recente vaste release te migreren: je combineert dan meerdere beveiligingsreparaties in één updatecyclus.
Snelle checklist voor beheerders
- Inventariseer welke servers Apache HTTP Server draaien en welke versie(s) je gebruikt.
- Check of HTTP/2 is ingeschakeld via de Protocols-richtlijn (serverbreed én per virtual host).
- Update naar 2.4.71 (of de distributie-equivalenten) zodra dat kan.
- Voor servers die niet direct kunnen patchen: verwijder h2/h2c en laat alleen http/1.1 over.
- Controleer of je ook draait met standalone mod_h2 en welke buildversie dat is.
Vergelijkbare risico’s: patchen en configuratie tellen
Dit incident past in een patroon dat je vaker ziet bij webservers en reverse proxy-achtige rollen: een relatief “specifieke” module kan toch directe RCE mogelijk maken wanneer het verkeer erop mag landen.
Als je bredere context wilt rond recente web- en platformkwetsbaarheden, is het nuttig om ook te kijken naar andere berichten over patchprioriteit en exploitkansen, zoals ICS Patch Tuesday en de risico’s rond Node2Shell. Ook al gaat dat over een ander domein, de les is vergelijkbaar: tijdig patchen en uitfaseren van kwetsbare services maakt het verschil.
Conclusie
De kwetsbaarheid CVE-2026-119618 in Apache HTTP/2 (mod_http2) maakt Apache HTTP/2 RCE mogelijk: een aanvaller kan op afstand code uitvoeren zonder authenticatie. De meest effectieve maatregel is updaten naar Apache HTTP Server 2.4.71 of de equivalente gepatchte pakketten van je distributie.
Lukt patchen niet meteen, schakel dan HTTP/2 uit door h2 en h2c te verwijderen uit Protocols. Door dit snel te doen, verlaag je de blootstelling aanzienlijk en voorkom je dat een kwetsbare module bereikbaar blijft voor aanvallers.
Bron: https://thehackernews.com/2026/11/critical-apache-http2-flaw-could-let.html
