curl heeft een beveiligingslek verholpen dat ontstaat bij curl HTTP/2 upload. Volgens de melding kan een kwaadwillende server tijdens een upload de client in een onveilige geheugentoestand brengen, waardoor uiteindelijk code-uitvoering mogelijk wordt op de machine die uploadt. De correctie is uitgebracht op 14 oktober en zit in curl 8.23.0 en bijbehorende updates voor oudere branches.
Omdat de aanval precieze omstandigheden vereist—zoals kennis van de build en het geheugenmodel—zijn succesvolle exploits niet eenvoudig. Toch is het verstandig om direct actie te nemen, zeker als je curl of libcurl gebruikt in productieomgevingen of in applicaties die bestanden ophalen of uploaden via HTTPS.
Wat is er mis bij de curl HTTP/2 upload?
Het probleem betreft de manier waarop curl omgaat met HTTP/2 uploads. Wanneer een server de HTTP/2-stream op een specifieke manier manipuleert, kan curl een deel van de uploaddata opruimen en daarna toch nog verwijzen naar een object dat al is vrijgegeven. Dat patroon wordt in de advisory aangeduid als een use-after-free (CVE-2026-92392).
In de kern draait het om een mismatch tussen wat curl denkt dat er nog “actief” is en wat er daadwerkelijk nog gebruikt wordt bij verdere afhandeling van de verbinding. Hierdoor kan data die van de server komt, in geheugen terechtkomen dat intussen een andere betekenis heeft gekregen.
Effect: van geheugenfout naar (potentiële) code-uitvoering
De researcher liet zien dat het scenario kan escaleren naar code execution op de uploading host. Daarvoor moet de aanvaller een set randvoorwaarden combineren:
- De aanval start aan de serverkant: de server stuurt de client zo aan dat curl in de verkeerde opruimlogica belandt.
- De client moet een bestand van ongeveer 135 KB uploaden via HTTP/2.
- Het servercertificaat moet door de certificaatchecks van de client komen.
De uitvoerbaarheid hangt bovendien sterk af van timing, target-details en het interne geheugenlayout. curl zelf schat daarom de kans op een werkende aanval als beperkt in—het lek is daarom geclassificeerd als High op de eigen schaal.
Welke versies zijn kwetsbaar?
De kwetsbaarheid beïnvloedt curl en libcurl in de reeks 8.12.0 t/m 8.22.0. Het gaat niet alleen om het commandoregelprogramma, maar om libcurl, dat door veel applicaties wordt gebruikt voor uploads en downloads.
Omdat HTTP/2-onderhandeling onderdeel is van libcurl’s mogelijkheden, speelt ook de manier waarop je libcurl is gebouwd een rol. libcurl met HTTP/2-ondersteuning kan HTTP/2 gebruiken voor https://-URLs wanneer de server dat aanbiedt.
De oplossing: upgrade naar curl 8.23.0
De meest directe maatregel is een upgrade naar curl 8.23.0. curl vermeldt daarnaast ook fixes voor oudere onderhoudsbranches:
- curl en 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): 8.14.1-2+deb13u7 via DSA-6558-1 (volgens de Debian-tracker)
- Debian 12 (bookworm): bevat volgens de bron niet de kwetsbare code
curl geeft aan dat de fix in de release ook onderdeel is van een bredere set CVE-afhandeling: in totaal werden er 24 CVE’s opgelost, terwijl de overige 23 issues als Low worden beoordeeld.
Wat te doen tot je hebt geüpgraded
Kun je nog niet upgraden? Dan adviseert curl om HTTP/2 niet te gebruiken voor verzoeken die uploaden. De praktische omweg is om HTTP/1.1 af te dwingen.
Voor curl kun je daarvoor de optie --http1.1 gebruiken. In applicaties die libcurl inzetten, gebeurt dat door CURLOPT_HTTP_VERSION in te stellen op CURL_HTTP_VERSION_1_1. Let op: curl beschrijft dit als een “request” en houdt rekening met hergebruik van bestaande verbindingen.
Daarnaast geldt: als jouw libcurl is gebouwd zónder HTTP/2-ondersteuning, kan het de betreffende uploadroute niet bereiken. Toch is dat geen vervanging voor een upgrade—zeker niet als je afhankelijk bent van meerdere transportmogelijkheden.
Waarom de aanval niet triviaal is
Om van use-after-free naar werkende exploit te komen, moet de aanvaller heel precies zijn. In de advisory en uitleg wordt aangegeven dat de aanvaller kennis nodig heeft over onder meer de exacte curl-versie, architectuur, libc allocator en heap-layout. Ook moet de server passende frames en timing leveren om een bruikbare toestand te creëren.
De meest waarschijnlijke uitkomst van een poging is volgens de toelichting daarom eerder een crash dan succesvolle code-uitvoering. Dat is precies de reden dat curl het niet als Critical maar als High beoordeelt.
Updateproces als je curl gebruikt in systemen
Omdat libcurl breed wordt toegepast, is het verstandig om je inventaris op te bouwen:
- Gebruik je zelf curl in scripts of automation (CI/CD, cronjobs, onderhoudstools)?
- Gebruiken je applicaties libcurl onder water (bijvoorbeeld via tussenbibliotheken of tooling)?
- Hoe wordt HTTP/2 geconfigureerd: staat het expliciet aan/uit, of is het “automatisch” gedrag via TLS/onderhandeling?
Wil je dit meenemen in je bredere aanpak voor “minder vertrouwen, beter beheersen” rond externe verbindingen? Zie ook onze achtergrond over Zero Trust en identity-strategieën.
Relatie met beveiligingsupdates in de praktijk
curl is een kerncomponent in veel omgevingen. Daarom sluit deze update aan bij het bredere beeld dat beveiligingsfixes vaak snel moeten worden opgevolgd—zeker wanneer transportlagen (zoals HTTP/2) in het spel zijn. Als je daarnaast werkt met andere protocol-specifieke componenten, dan is het nuttig om je patchproces ook langs die lijnen te organiseren.
Voor teams die een vaste cadence volgen, helpt het om updates te vergelijken met andere patchmomenten, zoals bij softwarepakketten in industriële omgevingen. Een voorbeeld daarvan is ICS Patch Tuesday: focus op Siemens & Rockwell—niet omdat het dezelfde kwetsbaarheid betreft, maar omdat het laat zien hoe belangrijk het is om patchprioriteiten gestructureerd aan te pakken.
Conclusie: neem de curl HTTP/2 upload fix serieus
De kwetsbaarheid achter curl HTTP/2 upload (CVE-2026-92392) laat zien hoe een server-side manipulatie van HTTP/2-streams kan doorwerken naar onveilig geheugenbeheer op de client. Hoewel een werkende exploit volgens curl niet “default” is en veel kennis en timing vereist, is de impact op zijn minst reden om snel te handelen.
Werk daarom toe naar curl 8.23.0 (of de equivalente fixes voor jouw onderhoudsbranch). Lukt dat nog niet? Forceer dan HTTP/1.1 totdat de update doorgevoerd is. Zo verklein je de kans dat je getroffen wordt door precies dit aanvalspad.
Bron: https://thehackernews.com/2026/10/curl-patches-http2-upload-flaw-after.html
1 reactie