Na PHP nu Node.js, Java en Python: wennen aan vaker patchen
Na de PHP-lekken van deze week vragen ook Java, Node.js en Python-pakketten om beveiligingsupdates. Ik denk dat we aan dit tempo van meldingen en patches gaan moeten wennen. En dat developers daar nog volop werk in hebben.
Tweakers schreef over het Node.js-lek (opent in een nieuw tabblad). Het lek, CVE-2026-111497, zit in Brotli, een bibliotheek die gecomprimeerde data uitpakt. Node.js bracht op 21 oktober patches uit (opent in een nieuw tabblad) in de versies 22.23.4, 24.22.1 en 26.12.1, en vermeldt OpenAI Codex Security als ontdekker. Imperva toonde aan (opent in een nieuw tabblad) dat een aanvaller via dat lek eigen code kon laten uitvoeren op Node.js 24.22.0. De gepatchte versie weigerde dezelfde invoer.
Dezelfde decoder zit in de Python-pakketten Brotli en brotlicffi (opent in een nieuw tabblad), opgelost in 1.2.1 en 1.2.1.0. Aikido legt uit (opent in een nieuw tabblad) dat HTTP-clients zoals requests en httpx die automatisch gebruiken als ze geïnstalleerd zijn. Je eigen code hoeft Brotli dus niet eens rechtstreeks aan te spreken.
Oracle bracht ook patches voor Java SE uit (opent in een nieuw tabblad). Dat zijn afzonderlijke problemen. Het NCSC beoordeelt bij het Brotli-lek (opent in een nieuw tabblad) de kans op misbruik als gemiddeld en de mogelijke schade als groot. Op 23 oktober was er nog geen bewijs van actief misbruik.
Vaker lekken vinden en sneller herstellen
OpenAI verwacht dat zulke vondsten de komende maanden sterk toenemen (opent in een nieuw tabblad). Het beschrijft ook hoe AI kan helpen met fixes en tests, terwijl maintainers en beveiligingsexperts die controleren. Aanvallers krijgen die mogelijkheden evengoed.
Bij Java is dat al concreet. Oracle bracht op 18 augustus een eerste maandelijkse Java-update uit (opent in een nieuw tabblad), naast het vertrouwde kwartaalritme. De volgende staat gepland voor 17 november. Oracle noemt AI expliciet als reden: lekken worden sneller en op grotere schaal gevonden en opgelost. Teams moeten hun tests en uitrol daarop voorbereiden.
Ik verwacht dat dit de nieuwe realiteit wordt. Vaker patchen gaat af en toe pijn doen, zoals we bij PHP zagen.
Op termijn denk ik wel dat software hier veiliger door wordt. Elk lek dat vroeg gevonden en degelijk opgelost wordt, is er één minder in de bibliotheken waar we allemaal op bouwen. Maar een gevonden lek blijft een risico zolang de patch niet draait. Brotli toont dat goed: volgens Aikido was de oorzaak al in februari opgelost in de broncode. Niemand zag het toen als beveiligingsprobleem, er kwam geen release, dus draaide de fix nergens.
Developers als bouwers en agent-teamleads
Dat werk doet zichzelf niet. Iemand moet beslissen wat er gepatcht wordt, hoe, en of het veilig live kan. Daarom geloof ik dat ons beroep blijft bestaan. Developers worden meer bouwers, architecten, agent-teamleads en beveiligers. We typen minder zelf. Bepalen wat er gebouwd wordt, hoe de onderdelen samenwerken en of het resultaat te vertrouwen is, wordt het eigenlijke werk.
Voor mij hoort daar goed en efficiënt delegeren naar AI bij. Een agent kan een wijziging voorbereiden, een andere kan de gevolgen voor de rest van de applicatie onderzoeken. Als developer bepaal je de opdracht, geef je de nodige context en controleer je of het resultaat klopt. Je moet ook kunnen ingrijpen als agents elkaar tegenspreken of een verkeerde aanname overnemen.
Neem die Brotli-update. Een agent kan uitzoeken via welke pakketten de bibliotheek binnenkomt, de nieuwe versies klaarzetten en de tests draaien. Maar of die analyse klopt, of de update vandaag live kan en wie ingrijpt als er toch iets breekt, beslist de developer. Die verantwoordelijkheid delegeer je niet. Het typen wordt minder belangrijk, de developer niet.