Een CVE-conflict

Een paar jaar geleden heeft het curl-project zich aangemeld en is het een CNA (CVE Numbering Authority) geworden. Dit betekent dat wij bevoegd zijn om onze eigen CVE-identificatoren toe te kennen. Voor alle beveiligingsproblemen binnen ons domein beslissen wij of een probleem een CVE krijgt of niet. Geen onterechte CVE's meer.

57 CVE's

In deze jaren hebben we tujuhenvijftig aparte beveiligingskwetsbaarheden gepubliceerd met de bijbehorende CVE-identificatoren. Het verkrijgen van een CVE voor een probleem is eenvoudig en gebeurt zeer snel wanneer je een CNA bent. Geen gedoe, geen wrijving, en aangezien we een klein en efficiënt securityteam zijn, werkt het zo soepel als je maar kunt wensen. Eén API-aanroep en we hebben een nieuw nummer.

Het zijn CNA zijn is onderhoudsarm, aangezien er echt niets extra's is dat we moeten doen. We hadden al een vastgesteld en bewezen proces voor het ontvangen, beheren en beoordelen van kwetsbaarheidsrapporten voordat we een CNA werden, omdat we een verantwoord en goed beheerd Open Source-project zijn. CNA worden heeft het proces simpelweg gemakkelijker gemaakt, omdat we nu geen externe partijen meer hoeven te betrekken.

Beoordeling

Voor elk rapport werken we hard om eerst vast te stellen en te beslissen of het probleem daadwerkelijk een kwetsbaarheid of een beveiligingsprobleem is.

Als we oordelen dat er sprake is van een beveiligingsprobleem, delen we dit vervolgens in als LOW, MEDIUM, HIGH of CRITICAL. Omdat we niet weten hoe gebruikers curl of libcurl gebruiken, kunnen we dat niet meewegen, maar bepalen we de ernst van het probleem puur vanuit het perspectief van curl.

Het is een globale indicatie van hoe wij het probleem zien, maar natuurlijk kan elke gebruiker die daadwerkelijk door het probleem wordt getroffen, het anders beoordelen.

Lager dan LOW

Voor een zeldzame weinige problemen kunnen we ons voorstellen dat er een minuscuul risico bestaat, maar vanwege de set extreme vereisten en ingewikkelde stappen om daar te komen, achten we het risico zo klein dat in de praktijk geen enkele gebruiker er waarschijnlijk ooit terecht zal komen. Intern noemen we dat een probleem met een ernstniveau "lager dan LOW". Problemen waarvan we geloven dat we de mensheid beter dienen door er geen CVE voor uit te geven, om de "security dance" te vermijden wanneer dit onnodig lijkt.

De kosten van een CVE

Libcurl is op ongeveer dertig miljard instanties wereldwijd geïnstalleerd. Als we ons voorstellen dat ten minste een aanzienlijk deel van die installaties wordt beheerd door mensen die ervoor willen zorgen dat ze een veilige versie gebruiken, betekent dit dat elke CVE die we publiceren activiteiten in gang zet bij veel securityteams over de hele wereld, wat leidt tot een aanzienlijk aantal patches en daaropvolgende software-updates.

Elke CVE heeft dus deze enorme kosten aan zich verbonden. Een kost die niet bij ons landt en die we niet echt zien of voelen, maar een kost voor het ecosysteem die we naar mijn mening niet mogen negeren. We moeten verantwoordelijk handelen. Natuurlijk nooit echte problemen negeren, maar ook ervoor zorgen dat we niet aan de bel trekken voor theoretische problemen die geen enkele kwetsbaarheid zullen triggeren.

Het conflict

Ons allereerste CVE-conflict sinds we een CNA zijn geworden, bereikte ons op 10 februari 2026, voor een rapport dat twee maanden eerder bij ons was ingediend. De melder vindt dat we een CVE hadden moeten toekennen aan het gemelde probleem, maar wij denken van niet. Nu willen ze de zaak forceren om toch een CVE te krijgen door de situatie te escaleren naar MITRE.

Ja, je vraagt je af waarom het zo belangrijk is om dit als een CVE te hebben, maar ik zal speculaties voor nu vermijden.

Ik heb MITRE geantwoord en uitgelegd dat we het probleem hebben overwogen en bediscussieerd en dat we tevreden blijven met onze eerdere beslissing. Ik heb hen verwezen naar het oorspronkelijke rapport en de discussie om dit aan te tonen.

Hostnaam met een beginnende punt

Het probleem is behoorlijk technisch (uiteraard), maar is gebaseerd op een bug in de functie van curl die controleert of de gebruikte hostnaam overeenkomt met een wildcard die in een certificaat wordt verstrekt.

Ten eerste: de gebruiker moet een hostnaam in een URL gebruiken met een beginnende punt, zoals https://.example.com/.

Deze naam is niet mogelijk om te gebruiken met DNS (het is daar een ongeldige naam), maar je kunt er een IP-adres voor opgeven in je /etc/hosts-bestand of iets dergelijks. Toch maakt deze voorwaarde het probleem al zeer niche.

Waarom zou een gebruiker dit ooit doen? Nou, er zou een redirect naar zo'n hostnaam kunnen zijn vanaf een kwaadaardige server als de applicatie redirects toestaat, maar het verkrijgen van het adres voor de host is nog steeds een uitdaging en vereist meestal de aanwezigheid van een lokale aanvaller om dat toe te voegen.

Vervolgens: als curl een adres kan vinden voor de ongeldige DNS-hostnaam, moet de site waarmee curl verbinding maakt ook een wildcard-certificaat hebben voor de naam *.example.com, waarbij het staartgedeelte van de wildcard moet overeenkomen met de naam in de URL.

Als curl is gebouwd om een OpenSSL-variant of Schannel te gebruiken voor TLS (denk eraan dat curl veel verschillende TLS-backends ondersteunt), roept het dan de functie Curlcerthostcheck() aan om te controleren of de wildcard de gebruikte hostnaam dekt.

Deze functie bevatte een bug. De bovenstaande combinatie zou dan onterecht TRUE teruggeven. Een match. Terwijl het in werkelijkheid geen match is volgens de specificatie.

We hebben dit probleem op 8 december 2025 opgelost en we hebben unit-tests toegevoegd voor precies dit scenario om ervoor te zorgen dat het probleem niet terugkeert. Voor alle beveiligingsproblemen die enkele niveaus onder HIGH zitten, lossen we ze zo snel mogelijk op, dus dat was gewoon onze normale procedure. We zijn daarna verder gaan discussiëren of dit een CVE waard was of niet.

Lager dan LOW

Het zou extreem zeldzaam moeten zijn dat iemand een naam gebruikt die met een punt begint, tenzij je in een interne en gecontroleerde omgeving bent waar je iets anders dan DNS gebruikt voor resolutie.

Het is niet mogelijk om een applicatie te misleiden om een willekeurige naam met een beginnende punt te gebruiken, omdat deze niet zal resolven.

De expliciet ingestelde, vreemd met een punt beginnende naam, moet vervolgens verbinding maken met een host die een wildcard heeft ingesteld voor diezelfde naam, en een aanvaller moet erin slagen om deze impostor-host te draaien en kan nu de applicatie kwaadaardige data serveren, omdat curl de verbinding niet correct weigerde vanwege de wildcard-mismatch.

Een reeks zeer onwaarschijnlijke omstandigheden die allemaal vervuld moeten zijn voordat dit een kwetsbaarheid wordt. Een "lager dan LOW" situatie. Te onwaarschijnlijk; geen CVE.

Opnieuw in mei

Op 28 mei werden we opnieuw benaderd door MITRE in dezelfde zaak, waarbij opnieuw werd gevraagd naar onze argumentatie voor het niet geven van een CVE aan dit probleem. We antwoordden met vrijwel dezelfde bewoordingen als voorheen en linkten opnieuw naar hetzelfde oorspronkelijke Hackerone-issue en discussiedraad. Het is eigenlijk allemaal openbare informatie.

Opnieuw in juni

Op 15 juni werden we opnieuw benaderd door MITRE met de vraag naar de redenering achter onze beslissing om geen CVE te geven voor dit probleem.

We antwoordden opnieuw met vergelijkbare bewoordingen. We linkten opnieuw naar hetzelfde issue.

Dit lijkt me een geweldig systeem.

Verdict

Op 24 juni kregen we eindelijk het verdict. Het wordt niet beschouwd als een beveiligingskwetsbaarheid.

Hallo Yuhao,

Bedankt voor je deelname aan het CVE-dispuutproces met betrekking tot het gemelde probleem dat curl tot en met 8.17.0 beïnvloedt.

De MITRE TL-Root heeft de review voltooid van de verstrekte informatie van alle betrokken partijen, inclusief de door jou ingediende materialen en de reactie van de verantwoordelijke CNA. Op basis van deze review heeft de MITRE TL-Root bepaald dat er geen CVE-ID zal worden toegewezen aan het gemelde probleem.

CNA-bepaling (samenvatting):

"Dit is een bug, nu opgelost in de master branch. Het wordt niet beschouwd als een beveiligingskwetsbaarheid vanwege de manier waarop een lokale aanvaller met privileges aanwezig moet zijn om dit mogelijk te maken."

Na evaluatie van het beschikbare bewijsmateriaal en de beoordeling van de CNA, is de MITRE TL-Root het eens met deze bepaling en beschouwt de zaak als opgelost. Als beslissende autoriteit in dit dispuutproces vertegenwoordigt de beslissing van de MITRE TL-Root de definitieve bepaling voor deze zaak.

We waarderen je betrokkenheid bij het CVE-programma en je inspanningen om beveiligingsproblemen verantwoord te rapporteren en te coördineren.

Respectvol,

MITRE TL-Root