Terwijl op woensdag 21 oktober 2026 alle aandacht naar het PHP-lek PHP2Shell ging, kwamen er nog twee kritieke beveiligingsupdates binnen: voor GitLab en voor Node.js. Beheer je je broncode in GitLab, of draait een van je applicaties op Node.js? Dan ging dit ook over je omgeving.
GitLab is het platform waarin softwareteams hun code beheren en waarmee ze applicaties automatisch testen en uitrollen. Node.js is de omgeving waarin JavaScript op een server draait, de basis onder veel moderne webapplicaties. Wij gebruiken ze allebei, en houden van elke applicatie bij welke versie waar draait. Daardoor wisten we na de aankondiging meteen wat er moest gebeuren, en konden we de ochtend erna gericht aan de slag.
Twee lekken die van buitenaf werkten
Het zwaarste lek in GitLab kreeg de hoogst mogelijke score: 10 op een schaal van 10. Iemand van buiten kon, zonder account of wachtwoord, de server opdrachten laten uitvoeren, via een fout in de manier waarop GitLab zoekpatronen verwerkt. Het lek zat in elke versie vanaf GitLab 7.0, al ruim tien jaar dus. Een tijdelijke maatregel bestaat niet; alleen bijwerken helpt. Het was bovendien de tweede keer in tien dagen: eerder deze maand repareerde GitLab al een vergelijkbaar lek met dezelfde score, gevonden door dezelfde onderzoeker. Had je toen netjes bijgewerkt, dan moest je opnieuw.
Node.js repareerde dezelfde dag tien kwetsbaarheden, vier daarvan ernstig. Het zwaarste zat in het uitpakken van gegevens die zijn gecomprimeerd met Brotli, een compressieformaat dat veel op het web wordt gebruikt. Een applicatie die zulke gegevens van buiten uitpakt, kon daardoor code van een aanvaller uitvoeren. Twee andere lekken maakten het mogelijk de controle van beveiligingscertificaten te omzeilen, de controle die moet garanderen dat een applicatie met de juiste server praat. De reparaties zitten in Node.js 22, 24 en 26. Voor oudere versies die geen ondersteuning meer krijgen, zoals Node.js 18 en 20, verschijnt niets: die blijven kwetsbaar.
Op het moment van schrijven melden GitLab en Node.js geen aanvallen die van deze lekken gebruikmaken.
Een GitLab-server is meer dan een archief
Dat een lek in GitLab score 10 krijgt, is ernstiger dan het klinkt. Wie een GitLab-server in handen krijgt, kan de broncode van elke applicatie erop lezen en aanpassen, en komt via de geautomatiseerde uitrol bij de servers waar die applicaties draaien.
Onze GitLab-server draait op onze eigen infrastructuur, niet bij GitLab zelf. Zo houden we in de hand waar de broncode van onze klanten staat, maar het bijwerken ligt dan ook bij ons. Woensdag ging op aan PHP2Shell. Donderdagochtend om 9:22 uur hebben we GitLab bijgewerkt naar een gerepareerde versie. GitLab zet daarbij ook zijn database om, dus de server was korte tijd onbereikbaar. Dezelfde ochtend volgden de Node.js-updates.
Waar Node.js bij ons draait
Onze applicaties zijn grotendeels in PHP ontwikkeld, maar Node.js draait op een paar vaste plekken mee. Omdat we die plekken bijhouden, met de versie die er draait, konden we per plek direct bepalen wat dit lek betekende.
Op de meeste plekken zit Node.js alleen in het bouwproces: het zet bestanden klaar voordat een site live gaat, ook bij onze eigen website. Op de server draait het dan niet, en van buitenaf kan niemand erbij. Waar Node.js wel op een server draait, als basis van een applicatie of als kleine dienst naast een PHP-applicatie, hebben we op 22 oktober bijgewerkt naar een gerepareerde versie. Waar dat zinvol was, zijn we meteen overgestapt op een versie met langere ondersteuning, zodat beveiligingsupdates voortaan automatisch meegaan.
Weken zoals deze komen vaker
Dat drie grote updates op dezelfde dag vielen, was toeval; GitLab en Node.js plannen hun releases los van elkaar. Interessanter is hoe de lekken gevonden zijn. Het GitLab-lek kwam op de klassieke manier boven, via een onderzoeker die het meldde bij het beloningsprogramma van GitLab. De andere twee niet. Het zwaarste Node.js-lek is gemeld door een team van OpenAI dat AI-modellen op broncode loslaat om fouten op te sporen, en ook PHP2Shell is met AI gevonden. Code die jarenlang door mensen is gelezen zonder dat iemand de fout zag, wordt nu op een andere manier gelezen, en dat levert wat op.
Daarom rekenen we erop dat dagen als 21 oktober de komende tijd vaker voorkomen. De PHP Foundation zei die week hetzelfde over haar eigen project. Op termijn is dat goed nieuws, want elk gevonden lek wordt gerepareerd. Voor wie een applicatie laat draaien, is het vooral praktisch: de update die je eens per kwartaal inplant, komt straks een paar keer tussendoor, en daar moet je onderhoud op ingericht zijn. Wij gebruiken AI inmiddels ook om onze eigen code op dit soort fouten na te lopen. Hoe zo’n toepassing er voor je organisatie uit kan zien, lees je bij AI-implementatie.
Wat je niet in beeld hebt, krijgt geen updates
Bij PHP2Shell zat de moeilijkheid in de timing: de reparatie bestond, maar was nog niet overal te krijgen. Deze keer lagen de updates direct klaar, en dan hangt de snelheid af van één ding: weten waar de software draait. Een GitLab-server zie je staan, maar Node.js meldt zich niet vanzelf. Het zit in een bouwstap, een hulpdienst of de basis van een applicatie, en elke plek vraagt een ander antwoord. Een bouwstap kan wachten op het reguliere onderhoud; een applicatie die van buitenaf bereikbaar is en op Node.js draait, moet dezelfde dag dicht. Elke applicatie leunt op software van anderen, van de programmeertaal tot kleine hulpdiensten, en elk van die onderdelen houdt op een dag op met updates. Voor GitLab 18.10 en ouder verscheen deze keer geen reparatie meer. Zit je op zo’n versie, dan moet je eerst upgraden voordat je kunt repareren.
Twee vragen kun je je leverancier daarom altijd stellen, ook als dat wij zijn. Welke software van anderen draait er in mijn applicatie mee? En wie houdt bij wanneer die geen updates meer krijgt? Een goed antwoord is een lijst met versies en einddatums. Hoe wij die lijst bijhouden, lees je bij doorontwikkeling en beheer.
Loop je vast op het antwoord, dan maken we dat overzicht graag met je.