curl en libcurl zijn opnieuw doelwit van een kwetsbaarheid die draait om HTTP/2 uploads. De curl HTTP/2 uploadfout laat een aanvallende server, onder specifieke omstandigheden, de clientgeheugenstructuren verstoren en kan zelfs uitmonden in code-uitvoering op de machine die uploadt. Het goede nieuws: het curl-project heeft de bug gefixt en je kunt vrij snel veilig(er) draaien door te upgraden of de patch toe te passen.
In dit artikel zetten we de kern van de kwetsbaarheid uiteen: wat er misgaat, welke voorwaarden gelden, hoe je de impact inschat, en wat je nu het beste kunt doen in je omgeving.
Wat is de curl HTTP/2 uploadfout?
De fout in curl gaat over de manier waarop HTTP/2-uploadstreams worden afgehandeld. In plaats van alleen een crash te veroorzaken, kan een kwaadwillende server ervoor zorgen dat curl in een use-after-free-situatie terechtkomt. Dat betekent dat de applicatie nog verwijst naar geheugen dat al “vrijgegeven” is, met als gevolg dat daar uiteindelijk verkeerde of gemanipuleerde data in terecht kan komen.
De kwetsbaarheid is geregistreerd als CVE-2026-92392. Ze treft curl en libcurl in de reeks 8.12.0 tot en met 8.22.0. Dat geldt zowel voor het command-line tool als voor de bibliotheek waar veel andere software op leunt voor netwerkverkeer en bestandsoverdracht.
Welke impact kun je verwachten?
curl classificeert de curl HTTP/2 uploadfout als High. Dat klinkt ernstig, en dat is het ook—maar met een belangrijke nuance: succesvolle code-uitvoering vraagt om een relatief complexe set voorwaarden. Volgens de release-uitleg is de meest waarschijnlijke uitkomst bij een poging eerder een crash dan geslaagde overname.
Voor code execution is er namelijk “precise knowledge” nodig over de doelomgeving: denk aan de exacte curl-versie, architectuur en details over de geheugenopbouw. Verder moet de timing kloppen zodat curl twee parallelle overdrachten in de juiste staat afhandelt.
Waarom speelt de serverkant een doorslaggevende rol?
Opvallend is dat de aanval vanaf de serverzijde start. De aanvaller controleert de server waarnaar de client uploadt. De client moet vervolgens een bestand uploaden van ongeveer 135 KB via HTTP/2 naar die server.
Ook moet het TLS-certificaat van die server slagen voor de verificatiechecks van de client. Met andere woorden: je kunt dit niet reduceren tot “elke server volstaat”—maar in scenario’s waarin clients naar ongecontroleerde of misbruikte endpoints uploaden, wordt het interessanter.
Wanneer wordt HTTP/2 gebruikt in libcurl?
De kwetsbaarheid is gekoppeld aan het HTTP/2 uploadpad. libcurl onderhandelt HTTP/2 voor https://-verzoeken wanneer de server HTTP/2 aanbiedt. Daarnaast gaat het om een build-optie: als je libcurl zonder HTTP/2-ondersteuning hebt gebouwd, kan de bibliotheek de betreffende route niet bereiken.
Als je nu tijdelijk moet uitwijken maar nog niet hebt geüpgraded, dan is het advies om HTTP/2 uit te schakelen. Praktisch betekent dat dat je curl/instellingen gebruikt die expliciet voor HTTP/1.1 kiezen (bijvoorbeeld met –http1.1 voor curl of met een overeenkomstige optie zoals CURLOPT_HTTP_VERSION in applicaties).
Wat gebeurt er technisch tijdens de aanval?
De publicatie licht een scenario toe waarin curl tijdens een upload de HTTP/2-window ziet “vastlopen” door de server. Vervolgens reset de server de stream terwijl de verbinding open blijft. curl interpreteert die reset als een reden om te retryen.
Daarna volgt een fase waarin curl eerst de HTTP/2-laag informeert dat de overdracht klaar is, en vervolgens nog restdata van de upload flush’t over dezelfde verbinding. Door de afhandeling kan die restdata vervolgens verkeerd als nieuw verzoek worden opgevat. Als de patroonherkenning van de bytes klopt, kan curl een nieuwe stream openen die in de interne structuur een pointer koppelt aan een object (de “easy handle”).
Wanneer de retry afrondt en de applicatie het handle-object vrijgeeft, kan de oude verbinding nog steeds een verwijzing vasthouden die niet meer geldig is. Zodra de server later een frame stuurt op de bijbehorende stream, kan het programma de verwijzing hergebruiken. In het beschreven exploitscenario “landt” aanvallerdata uiteindelijk in het geheugen dat voor de vrijgegeven handle bedoeld was.
Het resultaat is dat een functiepointer overschreven kan worden met bytes die afkomstig zijn van de server. Daarna wordt die pointer aangeroepen, wat tot code execution kan leiden.
Heeft deze aanval al in het wild plaatsgevonden?
Volgens de beschikbare informatie zijn er geen bronrapporten bekend die misbruik maken van deze specifieke fout. De publicatie meldt wel dat de rapportage en het bewijs openbaar zijn gemaakt met een HackerOne write-up, inclusief script en een Docker-constructie om de situatie te reproduceren.
Dat betekent niet dat het risico theoretisch is—wel dat je vooral moet reageren op een realistische kwetsbaarheid in een veelgebruikte component: curl/libcurl.
Zo herstel je de situatie: upgrade naar de fixed versie
De fix is opgenomen in curl 8.23.0, uitgebracht op 14 oktober. Het advies is daarom om direct te upgraden naar 8.23.0 of de fix commit toe te passen op een lokale build.
Het curl-project vermeldt ook updates voor oudere onderhoudstakken. In grote lijnen komt het hierop neer:
- curl/libcurl 8.12.0 t/m 8.22.0: upgrade naar 8.23.0
- 8.14.x: 8.14.3
- 8.16.x: 8.16.2
- 8.20.x: 8.20.2
- Debian 13 (trixie): updates lopen via het Debian tracker-advies (DSA-6558-1); Debian 12 draagt de kwetsbare code niet.
De release pakt bovendien in totaal 24 CVE’s mee. De overige kwetsbaarheden in die release vallen volgens de beschrijving buiten dezelfde “High” focus en worden laag ingeschat.
Tijdelijk mitigerende maatregelen als upgraden nog niet kan
Kun je niet meteen upgraden? Dan is het mitigatieplan volgens het curl-advies: voorkom dat HTTP/2 wordt gebruikt voor uploads. Kies voor HTTP/1.1 via curl-parameters of pas je app-instellingen aan zodat libcurl niet naar HTTP/2 onderhandelt.
Daarnaast is het verstandig om inventarisatie te doen: gebruik je curl direct, of indirect via software die libcurl inschakelt? Denk aan tooling, integraties en applicaties die data uploaden naar externe endpoints.
Waarom dit ook je software supply chain raakt
curl is niet alleen een “losse tool”. Het is een bouwsteen die door tal van applicaties wordt benut. Dat maakt de curl HTTP/2 uploadfout een supply chain-achtige uitdaging: je hoeft de kwetsbaarheid niet zelf te schrijven om hem toch in je stack te hebben zitten.
Als je beleid hebt rond patchmanagement, draai dan ook een controle op runtime- en buildvarianten. Bijvoorbeeld: is er een libcurl gebruikt die HTTP/2 wel ondersteunt? En welke versie draaien je containerimages of hosts in productie?
Voor bredere context over hoe kwetsbaarheden via veelgebruikte componenten verspreid kunnen raken, kun je ook kijken naar dit soort updates en incidentlessen op je site: wat de Docker Hub bug laat zien over misbruik van tokens.
Betrek security niet alleen bij de upgrade: controleer gebruik van HTTP/2 uploads
Zelfs met de juiste versie is het nuttig om te begrijpen hoe je omgeving met uploads omgaat. De aanval vereist uploadgedrag via HTTP/2 naar een server die de aanvaller controleert. Daarom zijn logging, netwerkobservatie en endpointbeheer relevant.
Stel jezelf daarom deze vragen:
- Welke systemen uploaden via curl/libcurl en naar welke domeinen?
- Wordt daar HTTP/2 geactiveerd door onderhandeling met servers?
- Zijn er interne processen of derde partijen die uploads naar niet-gesanctioneerde targets kunnen uitvoeren?
- Heb je een mechanisme om certificaatchecks en trust anchors te bewaken?
Conclusie: pak de curl HTTP/2 uploadfout nu aan
De curl HTTP/2 uploadfout (CVE-2026-92392) combineert een use-after-free met een aanvalsvector die server-side wordt aangestuurd en die, bij juiste omstandigheden, kan leiden tot code execution. Er zijn geen openbare meldingen van actief misbruik bekend, maar je kunt het risico niet negeren: curl/libcurl is breed aanwezig en de fix is beschikbaar.
Upgrade daarom naar curl 8.23.0 (of de bijbehorende maintenanceversies) en voorkom tijdelijk HTTP/2 uploads als je nog niet klaar bent. Door zowel versiebeheer als HTTP/2-gebruik in je omgevingsanalyse mee te nemen, maak je de kans op impact aanzienlijk kleiner.
Bron: https://thehackernews.com/2026/10/curl-patches-http2-upload-flaw-after.html
