Een gerucht over een bug is tegenwoordig al genoeg om een security exploit te vinden

Ik heb vandaag een beveiligingsfix uitgebracht voor OCaml's cohttp 6.3.0 om een probleem met path traversal op te lossen.

De patch zelf was eenvoudig. In normale tijden zou de beveiligingsprocedure zijn geweest om het privé op te lossen, getroffen gebruikers te informeren en vervolgens een openbaar advies uit te brengen. Deze keer merkte ik echter dat er, slechts enkele minuten nadat ik de PR om het probleem op te lossen had geopend, al probes in mijn live webserver-logs stonden met exact hetzelfde bug-patroon.

Wat erger is: ik ontdekte dat ik mijn eigen agents kon gebruiken om de exploit te vinden, simpelweg door ongeveer te weten waar het over ging. Ik had het lek dus al kunnen exploiteren ruim voordat de publieke patch beschikbaar was!

Gezien het feit dat alleen al het gerucht over een beveiligingsprobleem aanvallers genoeg informatie lijkt te geven om nieuwe exploits te vinden, moeten we de manier waarop we reageren op beveiligingsproblemen in open source aanpassen.

1. Een gerucht over een bug is alles wat nieuwe agentic exploit-systemen nodig hebben

Dit specifieke rapport kwam vorige week privé binnen via een Slack-kanaal van Jane Street, en was zelf gevonden via Claude Fable. Dat verkort alle tijdlijnen aanzienlijk.

1.1 De tijdlijn van een modern beveiligingsrapport

Voordat ik de patch in detail bekeek, richtte ik mijn eigen Claude op de getroffen code om te zien wat er nog meer verborgen zat (met de vraag om onderzoek te doen naar problemen met path normalisation). Fable weigerde dit frustrerend genoeg vanwege een beveiligingsblokkade (omdat ik geen toegang heb tot Glasswing), maar DeepSeek V4 Pro deed het wel en vond onafhankelijk van elkaar verschillende gerelateerde problemen. Mijn agent creëerde bovendien binnen een minuut een exploit om een lokale live server te testen.

Na wat overleg met de melder over mogelijke oplossingen, heb ik cohttp#1145 stilletjes openbaar gemaakt om meer mensen ernaar te laten kijken. Normaal gesproken duurt dit een paar dagen, en een release binnen een week of twee is redelijk. Binnen ongeveer tien minuten (!) kreeg deze website echter probes binnen voor percent-encoded traversal sequences. Dit wijst erop dat geautomatiseerde watchers publieke repositories nauwgezet in de gaten houden.

Als het mij slechts een minuut kostte om lokaal een exploit te maken, dan lijken tien minuten eigenlijk heel lang voor het begin van een geautomatiseerd aanvalstvenster. Een vastberaden aanvaller die pakket-repositories monitort, zou dit binnen enkele seconden kunnen exploiteren.

1.2 Beveiligingsembargo's zijn niet langer effectief

Het conventionele beveiligingsproces maakt gebruik van embargo's, vanuit de aanname dat geheimhouding van de details de gebruikers beschermt. Tegenwoordig heeft een agent echter alleen een globale richting nodig om in te zoeken en kan hij zelf onderzoek doen. Fang et al. ontdekten dat hun GPT-4 agent, wanneer hij een CVE-beschrijving kreeg, 87% van een benchmark met 15 kwetsbaarheden exploiteerde; zonder de beschrijving was dit slechts 7%.

Twee jaar later is de gemiddelde tijd tot exploitatie (mean time to exploit) -7 dagen. Met andere woorden: de exploitatie gaat nu aan de patch vooraf! Diezelfde metriek lag in 2018-19 rond de 63 dagen, maar kruiste in 2024 de nullijn. Een snelle zoektocht vindt tegenwoordig veel soortgelijke gevallen. Zo ging CVE-2026-39987 van marimo in 9 uur van advies naar de eerste exploitatiepoging, zelfs zonder publieke proof-of-concept. CVE-2026-33017 van Langflow duurde 20 uur. We lijken de Rubicon voor geautomatiseerde exploit-generatie te zijn overgestoken.

2. Zijn de "bugonomics" nu tegen de OSS-onderhouders?

Het lijkt me dat onze beveiligingsprocessen enigszins moeten keren. Eén persoon die zoekt naar een bepaalde klasse van problemen (dit kan een vraag op een mailinglijst zijn, een vreemde commit in een verweesde branch, of een context leak) is voldoende om de agent van iemand anders te waarschuwen en hen exploit-code te laten genereren. Dit is krankzinnig.

Een paper uit mei 2026 introduceerde de term "bugonomics" en stelt dat de flessenhals is verschoven naar de "doorvoersnelheid van herstel door de verdediger" (defender remediation throughput). LLM's genereren vrolijk exploits, maar ons vermogen om ons ertegen te verdedigen verbetert niet noodzakelijkerwijs, omdat de snelheid van validatie, triage en releases door onderhouders gelijk blijft. Dit komt helaas overeen met mijn perspectief als OSS-onderhouder:

"De vraag is niet of frontier-modellen, open-weight modellen of programmanalyse 'winnen'. De vraag is hoe we ze orkestreren zodat de schaarse capaciteit voor validatie, prioritering en release wordt ingezet voor duurzame oplossingen in plaats van mechanisch zoeken en het opstellen van rapporten. Een centrale kans voor de verdediger is het aanpakken van technische schuld: workflows die gebaseerd zijn op semantiek, geverifieerd door tools en ondersteund door modellen, die onderhouders helpen beveiligingsrelevante defecten te vinden, valideren, prioriteren en oplossen voordat ze de exploits van morgen worden."

— Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026

En waarom blijven de capaciteiten van onderhouders gelijk? Het gebrek aan toegang tot frontier-agents zoals Mythos is een duidelijke reden, maar ook het feit dat het engineeren van een beveiligingspatch die geen regressies veroorzaakt, fundamenteel meer werk is.

3. Wat kunnen we hieraan doen?

We moeten ons snel aanpassen. Ik denk niet dat het huidige handmatige triageproces moet verdwijnen, maar ik heb een onhoudbare toename van activiteit gezien sinds de komst van Fable. We beginnen pas net grip te krijgen op hoeveel van de binnenkomende stroom machine-gegenereerd is, maar het is overduidelijk veel.

Grote engineering-bedrijven (zoals Google) hebben microupdates direct in hun software ingebouwd om ervoor te zorgen dat fixes de gebruikers prioriteren boven bijvoorbeeld een fix in de Chrome-coderepository. Wij hebben die luxe niet in Docker of OCaml, omdat we de eindpunten waar onze software wordt gebruikt niet controleren. Behalve Docker Desktop herpakken downstream-distributies OSS terecht op hun eigen tijdsschema's en voorwaarden.

Voor kleinere projecten zoals OCaml is zelfs het krijgen van toegang tot frontier-modellen een strijd. Westerse modellen hebben beveiligingsfilters waardoor we de commercieel beschikbare modellen niet kunnen gebruiken. Project Glasswing is uitgebreid naar 150 organisaties in 15 landen, inclusief exploitanten van kritieke infrastructuur, cloud- en financiële providers en de Linux Foundation, maar 'mom and pop' onderhouders hebben nog steeds geen toegang. In april was ik ambivalent over of dit schadelijk was, maar vandaag is het duidelijk dat dit erg slecht uitpakt.

3.1 Supergeheime private patch-ontwikkeling

De eerste oplossing is om fixes te ontwikkelen op een plek die echt privé is en buiten het bereik van AI. De tijdelijke private forks van GitHub doen dit nominaal, maar dat werkt niet erg goed voor ons.

Ten eerste beperkt GitHub dit: "om informatie over kwetsbaarheden veilig te houden, kunnen integraties, waaronder CI, geen toegang krijgen tot tijdelijke private forks", wat de onderhouder direct loskoppelt van de resultaten van onze CI. Ten tweede kan slechts één PR naar de fork worden samengevoegd, wat niet goed werkt voor problemen die vaak over meerdere repositories verspreid zijn. Reviewers moeten ook één voor één door een beheerder worden aangemeld, terwijl reviewers in de open-source wereld vaak 'drive-by' zijn, afhankelijk van wie beschikbaar is.

Breder gezien dichten we hiermee het verkeerde lek. Het geheim houden van de patch is minder belangrijk dan ervoor zorgen dat de beschrijving van het probleem precies de juiste mensen bereikt, zonder lekken naar aanvallers. We hebben geen robuuste discussie-infrastructuur binnen OSS; dit is verspreid over verschillende end-to-end versleutelde kanalen (wij gebruiken Matrix), maar ook over gedeelde infrastructuur zoals Discord of Slack, die extreem lek zijn. We hebben een soort web-of-trust nodig om de goede mensen van de slechte te onderscheiden in een specifieke projectcontext.

3.2 Geen embargo's, maar continu verzenden

Een andere optie is om problemen snel in het openbaar op te lossen, continu versies uit te brengen en het releaseproces te verbeteren via betere automatisering.

Grotere projecten zoals Chrome laten zien dat dit mogelijk is via wekelijkse beveiligingsupdates (twee releases per week!) en dynamische patching die achtergrondprocessen vervangt door bijgewerkte binaries zonder herstart. Dit is geen geheel nieuwe technologie; ik heb 15 jaar geleden al gekeken naar de integratie van live ksplice Linux-patching met Xen. Ook de Linux-kernel verzendt fixes zo snel mogelijk, met een uitstel van maximaal zeven en in uitzonderlijke gevallen veertien dagen.

De primaire hindernis is echter de softwareverpakking (software packaging). Chrome heeft de relatief eenvoudige taak om één binair artefact te verzenden, maar OSS bestaat vaak uit een verzameling bibliotheken die vervolgens worden ingebed in diverse downstream-producten. Om dit te realiseren hebben we het volgende nodig:

• Veel betere cross-ecosysteem pakketbeheer om te ontdekken waar verschillende bibliotheken uiteindelijk in zijn ingebed.
• Betere scanning-tools om te helpen bij de triage.
• Robuustere kwaliteitscontrole-infrastructuur zonder valse positieven, die werkt over het hele spectrum van ondersteunde platforms (zoals OpenBSD, FreeBSD, macOS en architecturen zoals RISC-V).

3.3 Proactieve bescherming op protocolniveau

Ik heb ook radicalere gedachten over hoe we dynamisch bescherming kunnen inzetten om eindpunten die onze bibliotheken gebruiken te beschermen. Als we accepteren dat upstream-patches altijd achterlopen op een exploit, moeten we iets snellers inzetten.

Bijvoorbeeld: de cohttp-bug die vandaag is opgelost, heeft een eenvoudige mitigatie: normaliseer simpelweg percent-encoded path separators in de request-URL. Deze regel was implementeerbaar op het moment dat het rapport arriveerde, en kon worden uitgerold terwijl de volledige fix door review, testen en verpakking ging. Virtual patching is tegenwoordig routine op cloud-infrastructuur; Cloudflare implementeerde beheerde regels om Log4shell in 2021 te dichten.

Maar open source mist een distributiemechanisme voor dergelijke regels buiten een commerciële CDN. Dat is wat het idee van het antibotty-netwerk probeert op te lossen via meer software-diversiteit over het wereldwijde internet. Hoe kunnen we lokale, snel propagerende verdedigingen hebben die horen over een kwetsbaarheid en binnen enkele seconden actie ondernemen op hun directe infrastructuur?

4. Vervolgonderzoek

Ik denk dat we op korte termijn een combinatie van deze drie opties nodig hebben: een lichtgewicht web-of-trust voor OSS-bijdragers, meer focus op OSS-verpakking, en continue rollout- en triage-mechanismen die onze kostbare menselijke bijdragers niet overweldigen.

Ik heb ook een paar nieuwe MPhil-onderzoeksideeën geplaatst voor wie volgende maand naar Cambridge komt:

• "An antibotty defensive testbed to protect network services": plaatst een MirageOS-gateway voor een thuisnetwerk en onderzoekt of een set mitigatieregels betrouwbaar genoeg gemaakt kunnen worden om automatisch uit te rollen. Er is een leuk capture-the-flag spel te spelen door hetzelfde gerucht aan een aanvallende agent en een verdedigende agent te geven en te zien wie er als eerste is.
• "Compiling Lean specifications into OxCaml enforcement automata": definieert wat een bibliotheek mag doen over filesystem-, parser- en netwerklagen met behulp van Dijkstra-monaden. Dit compileert die Lean-specificatie naar een OxCaml-automaton die dit tijdens runtime afdwingt.

En als er iemand van Project Glasswing meeluistert: team OCaml kan nu wel toegang gebruiken :-)

***

(De cohttp-fix was geen soloprestatie. Sapphire Livingstone vond en rapporteerde het probleem, begeleidde de fix en ontwikkelde mee aan de oplossing; Michael Dales, Török Edwin en Patrick Ferris reviewden de patch; Hannes Mehnert coördineerde het advies; en Thomas Gazagnaire heeft nagedacht over het bredere triageprobleem. Dank aan jullie allemaal! De bugonomics mogen tegen ons zijn, maar we komen hier doorheen.)

Referenties

[1] Madhavapeddy et al (2025). Functional Networking for Millions of Docker Desktops. 10.1145/3747525 [2] Madhavapeddy (2026). Language integrated LLMs as an OCaml function. 10.59350/61cdd-r5a25 [3] Madhavapeddy et al (2025). Steps towards an Ecology for the Internet. Association for Computing Machinery. 10.1145/3744169.3744180 [4] Madhavapeddy et al (2026). A Decade of Docker Containers. 10.1145/3761803 [5] Madhavapeddy (2026). Rewilding the Web: my workshop report from Edinburgh. 10.59350/g40yy-ks003 [6] Madhavapeddy (2026). The Internet needs an antibotty immune system, stat. 10.59350/snnnf-asc02 [7] Madhavapeddy (2009). Combining Static Model Checking with Dynamic Enforcement Using the Statecall Policy Language. Springer. 10.1007/978-3-642-10373-5_23 [8] Gibb et al (2026). Package Managers à la Carte: A Formal Model of Dependency Resolution. arXiv. 10.48550/arXiv.2602.18602 [9] Fang et al (2024). LLM Agents can Autonomously Exploit One-day Vulnerabilities. arXiv. 10.48550/arXiv.2404.08144 [10] Pesoli et al (2026). Demystifying the Mythos or Disrupting Bugonomics? From Zero-Day Asymmetry to Defender Remediation Throughput. arXiv. 10.48550/arXiv.2605.24632