Is dit het nieuwe cyber-normaal?

De bugs

Om te begrijpen wat er momenteel gebeurt in de wereld van softwarebeveiliging, moeten we kijken naar de specifieke bugs. Omdat ik geen cybersecurity-expert ben, verwijs ik voor de technische details naar externe bronnen.

PHP2Shell – CVE-2026-109618 en CVE-2026-109619 (ook bekend als "the big one in the news")

Twee verschillende securityteams — één van het Californische beveiligingsbedrijf Calif (als onderdeel van het "Patch the Planet"-programma van OpenAI) en een ander van het Israëlisch-Amerikaanse cloudbeveiligingsbedrijf Wiz (onderdeel van Google Cloud) — ontdekten beide twee Remote Code Execution (RCE) bugs in PHP. Beide teams maakten gebruik van geavanceerde AI-modellen (LLM's, specifiek GPT-5.6 Sol/Gemini 4 Argon) om deze kwetsbaarheden te vinden en exploits te bouwen.

Interessant is dat een van de bugs (CVE-2026-109618) al was gevonden tijdens een security-audit van de PHP Foundation in 2024 (gefinancierd door de Sovereign Tech Agency). Deze werd echter grotendeels genegeerd omdat men het niet eens kon worden over een oplossing en niemand kon uitzoeken hoe men een daadwerkelijke exploit kon maken op basis van het theoretische probleem.

LLM's zijn zeer effectief in het omzetten van een theoretische kwetsbaarheid — zelfs een vage beschrijving — naar een volledige exploit. Dit is de laatste maanden een groot probleem geworden: zodra een security-patch wordt aangekondigd, richten mensen hun LLM's op de codebase. De AI-agenten kunnen razendsnel door de 'diffs' lezen tot ze een patch vinden, teruggaan naar de kwetsbaarheid die werd gedekt en dit proces volgen tot aan een werkende exploit.

Dit proces gaat zo snel dat het inmiddels redelijk is om aan te nemen dat het moment van de aankondiging van een patch de uiterste datum is waarop een volledige exploit nog niet publiekelijk of privaat wordt verspreid.

PHP2Shell wordt geschat te beïnvloeden van 70% van het internet, met duizenden websites, variërend van de Wikimedia Foundation en DeviantArt tot grote delen van de Britse overheid, Japanse banksystemen en de website van het BBC-programma The Traitors. Normaal gesproken leiden kwetsbaarheden niet tot het massaal offline halen van servers door de helft van het internet. Wat is hier aan de hand?

Een lek in de communicatie versnelde de paniek. Iemand genaamd petecooper plaatste informatie over de CVE's op Hacker News, onbewust van een embargo. Dit leidde tot een overhaaste verklaring van de PHP Group en het vervroegen van de patch. De onbedoelde lekken bevatten CVSS-scores van 10.0 (hoewel de werkelijke scores 9.2 waren).

Tegen de tijd dat de patch daadwerkelijk werd uitgebracht, werd de kwetsbaarheid al in het wild misbruikt¹. De PHP Foundation gaf Calif en Chainguard de schuld: Calif zou een video van de exploit in actie hebben gelekt (met vreemde achtergrondmuziek en een dansende anime-girl), terwijl Chainguard fixes publiceerde zes uur voordat het embargo verliep.

Er is veel discussie over de vraag of AI de gamechanger is die computerbeveiliging revolutioneert. Sommigen beweren dat PHP2Shell overdreven is omdat LLM's vaak "exploit slop" produceren: exploits die gebaseerd zijn op foutieve aannames en niet werken. Echter, zoals LiveOverflow opmerkt: je kunt 10.000 slecht functionerende exploits hebben, maar als er één is die wél werkt, is dat het enige dat telt.

De belangrijkste conclusie is dat de tijd tussen "ik hoorde dat er een slechte RCE is in dit project" en "er zijn geavanceerde, geautomatiseerde aanvallen met een exploit" is verkort van weken/maanden naar uren/minuten.

Bronnen:

• Hacker News: “Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming” (petecooper, 20 okt 2026)
• PHP2Shell – officiële website
• Wiz Research: “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”
• PHP News Archive: “Upcoming Critical PHP Security Release” (20 okt 2026)
• Wikipedia: PHP2Shell
• AWS Security Blog: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”

eMudhra (CVE-2026-111943 voor Golang response)

Op dezelfde dag (20 oktober 2026) kondigde Mozilla aan dat zij acht tussencertificaten blokkeerden die waren ondertekend door de Indiase certificeringsinstantie (CA) eMudhra. Dit gebeurde nadat een pseudonieme onderzoeker genaamd "Wayne" meldde dat de CA private keys van lachwekkend slechte kwaliteit gebruikte. Waar een veilige sleutel een getal van 100 cijfers zou moeten zijn, gebruikte eMudhra sleutels als "115", "56" en "4".

Er zijn geen aanwijzingen dat dit via AI is gevonden, hoewel onderzoeker Scott Helme opmerkt dat Claude met één prompt in staat was de private keys van de tussencertificaten te herstellen. eMudhra heeft inmiddels aangekondigd zich terug te trekken uit de sector van certificeringsinstanties.

Bronnen:

• Mozilla Security Blog: “Protecting Firefox users following the compromise of eMudhra intermediate certificates”
• Scott Helme: “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds”
• eMudhra persbericht: “eMudhra to Exit global SSL/TLS Certificate Business”
• eMudhra Intermediate CA Compromise – onderzoeksaankondiging en trust store checker

Railway bug

De volgende dag kondigde cloudprovider Railway aan dat hackers toegang hadden gekregen tot en zelfs omgevingsvariabelen (environment variables) hadden ontsleuteld. Deze variabelen bevatten vaak geheimen zoals database-inloggegevens en API-sleutels. Railway gelooft dat dit deel uitmaakt van een gecoördineerde poging om bedrijven die AI-inferentie aanbieden te compromitteren.

Het is onduidelijk wat het einddoel is: spioneren naar het gebruik van AI-inferentie, het stelen van nieuwe modellen, of het opbouwen van een netwerk van gecompromitteerde providers voor eigen kwaadaardige doeleinden.

Bronnen:

• Railway Blog: “Security Disclosure: Wednesday October 21st”
• Hacker News discussie over de Railway security disclosure

GitLab (CVE-2026-97229 en CVE-2026-110264)

Op 12 oktober 2026 waarschuwde GitLab voor een bug met maximale ernst in de regular expression (regex) parsing van GitLab CI/CD, waardoor aanvallers willekeurige code konden uitvoeren (RCE) via een speciaal geconstrueerde regex. Dit kreeg een CVSS-score van 10.0. Op 21 oktober volgde nog een regex integer overflow RCE, eveneens met een score van 10.0.

Dit volgt kort na een andere 10.0 CVSS CVE van vorige maand (CVE-2026-85706) gerelateerd aan path traversal. Alle drie de bugs werden gemeld via het HackerOne bug bounty-programma van GitLab.

Hoewel GitLab breed wordt gebruikt in de academische wereld, bij overheden en in het bedrijfsleven, lijkt dit minder aandacht te hebben gekregen dan PHP2Shell. Toch is het zeer ernstig, aangezien veel intellectueel eigendom in GitLab wordt opgeslagen. Het risico wordt vaak verminderd door GitLab-instanties achter een VPN of firewall te plaatsen.

Er is geen aanwijzing dat deze bugs via AI zijn ontdekt.

Bronnen:

• GitLab Docs: “GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8”
• GitLab Docs: “GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13”
• Hacker News discussie: “GitLab critical patch release”
• BleepingComputer: “GitLab warns of max severity code execution vulnerability”
• Lobsters discussie: “GitLab warns of max severity code execution vulnerability”

musl libc bug

Op 21 oktober werd een bug in de libc van musl bekendgemaakt, gerelateerd aan regex. Dit leidt in ieder geval tot een denial of service, en mogelijk tot code-executie. Hoewel de timing samenvalt met de GitLab-bugs, lijkt dit puur toeval. De GitLab-bugs werden gevonden door de Zweed Johan Carlsson, terwijl de musl-bug werd gemeld door de Fransman Julien Voisin.

Bronnen:

• oss-security: “CVE-2026-107891: musl libc: multiple integer overflow in regcomp”
• Lobsters discussie: “musl regcomp CVE”

LiteLLM

LiteLLM is opnieuw getroffen. Deze keer gaat het om een kwaadaardige versie op de Python Package Index (PyPI) en in Docker-images. In maart gebeurde iets soortgelijks.

De aanval maakte gebruik van .pth-bestanden en het sitecutomize.py-bestand om kwaadaardige payloads automatisch te laden zodra de Python-interpreter start. Volgens analyse van Wiz zijn er "sterke aanwijzingen voor LLM-ondersteunde ontwikkeling" in de payload, zoals overdreven uitgebreide variabelenamen, zeer defensieve foutafhandeling en comments als "this is where it really bites" en "lean into that"⁴.

Volgens LiteLLM gebeurde het incident omdat de aanvaller toegang had tot inloggegevens voor de GitHub CLI. LiteLLM merkt op dat Claude Code soms GitHub CLI OAuth-tokens in responsen plaatst, die vervolgens in de logs van LiteLLM terecht kunnen komen.

Bronnen:

• Wiz Blog: “LiteLLM Compromised, Steals Credentials”
• LiteLLM: “Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised”
• Hacker News discussie: “Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor”

PingCAP

Op 19 oktober 2026 onthulde PingCAP, de ontwikkelaar van de database TiDB, dat er ongeautoriseerde toegang was tot hun systemen. Tegelijkertijd claimde de afpersingsgroep "FulcrumSec" (ook wel de "Threatspians"⁵) 10,6 TB aan data te hebben gestolen en publiceerde een torrent met 200 GB aan data als "eerste fase".

FulcrumSec publiceerde details over de slechte beveiligingspraktijken van PingCAP, waaronder het plaatsen van AWS secret access keys en ongeredigeerde logs (met OpenAI, Anthropic, Gemini en xAI API-sleutels) in Jira-tickets.

Hoewel PingCAP stelt dat er geen bewijs is dat data in TiDB is beïnvloed, lijkt 10,6 TB aan gestolen data erop te wijzen dat er wel degelijk veel klantgegevens zijn gelekt.

Bronnen:

• Hacker News discussie: “PingCap TiDB Leaks”
• PingCAP: “October 2026 Security Incident Report: Unauthorized Access to PingCAP Cloud Resources”
• FulcrumSec: “The PingCAP TiDB Cloud Leaks” (Let op: website van een cybercriminele groep)

Linux-kwetsbaarheden per ongeluk in verkeerde groep geplaatst

De ontwikkeling van de Linux-kernel verloopt via mailinglijsten. Beveiligingsgevoelige zaken worden besproken in private lijsten. In de nacht van 21 op 22 oktober 2026 rapporteerde de Zero Day Initiative (ZDI), eigendom van Trend Micro, echter een reeks CVE's met hoge ernst (CVSS 9.0+) op de publieke mailinglijst in plaats van de private. De aanname is nu dat iedereen met een LLM deze rapporten binnen enkele minuten kan omzetten in actieve exploits.

Bronnen:

• Phoronix: “Several Linux Kernel Vulnerabilities Accidentally Posted To Public Kernel Mailing List”

Is dit het nieuwe normaal?

De afgelopen dagen waren abnormaal actief wat betreft cyberincidenten. Sommigen beweren dat dit slechts het begin is en dat het alleen maar erger zal worden.

Hoewel veel discussies zich richten op AI en LLM's, werden niet alle lekken hiermee gevonden. We weten dat criminele en door staten gesteunde groepen AI gebruiken om sneller te hacken, maar veel van deze kwetsbaarheden zijn nog steeds "ouderwetse" softwarefouten gevonden door mensen. De online conversatie focust zich simpelweg op het nieuwe, enge element.

Het is begrijpelijk dat organisaties (zoals NHS England) hun open source-code privé willen maken, hoewel dat vaak een ondoordachte beslissing is. Wanneer LLM's zo goed worden dat iedereen een agent op open source-code kan zetten om kwetsbaarheden te vinden en exploits te schrijven, is dat zorgwekkend.

Wat kunnen we eraan doen?

De NHS-benadering: alles closed source maken

• Voordelen: Je code staat niet online, dus mensen kunnen geen LLM's gebruiken om commits te analyseren op security-fixes.
• Nadelen:
• De open source-community en de toekomst van computing lijden hieronder.
• Niet alles kan closed source worden (bijv. programmeertalen zoals Python).
• Code blijft closed source tot het gelekt wordt; zonder publieke controle is de code vaak juist minder veilig.
• LLM's kunnen tegenwoordig zelfs gecompileerde binaries effectief reverse-engineeren.
• Oude versies van de code staan vaak nog ergens online.

De AI-omarmers: vecht vuur met vuur

Het idee is dat we onze eigen, betere LLM's met meer budget en rekenkracht gebruiken om bugs te vinden voordat anderen dat doen.

• Voordelen: Vindt veel bugs; maakt een paar rijke tech-CEO's erg blij.
• Nadelen:
• Kost enorme hoeveelheden geld.
• Iemand moet de gevonden bugs nog steeds handmatig oplossen.
• Vereist nog steeds diepe technische expertise om AI correct in te zetten.

De optimist: universele standaarden

Het streven naar gestandaardiseerde methoden voor het rapporteren en mitigeren van kwetsbaarheden, waarbij elk bedrijf een top-notch security-posture heeft.

• Voordelen: Een prachtig idee; zou het probleem fundamenteel oplossen.
• Nadelen:
• We leven niet in die wereld en zullen dat waarschijnlijk nooit doen.
• Het is extreem duur en in de praktijk wellicht onmogelijk.

Er zijn wel "quick wins", zoals het nooit aankondigen van details van een kritieke kwetsbaarheid voordat de patch klaar is voor installatie. Echter, in het geval van PHP2Shell zorgden onbedoelde lekken ervoor dat iedereen al op de hoogte was vóór de officiële aankondiging.

Misschien moeten we accepteren dat alles wat je aan het internet blootstelt, uiteindelijk gehackt zal worden, en daarop plannen.

Conclusie

AI verandert de wereld van softwarebeveiliging, maar het is nog niet duidelijk of dit voor het betere of slechtere is. Er wordt ongelooflijk veel geld gepompt in AI, en dat vervormt vaak de waarheid.

Sommigen zeggen dat we nu een periode van escalerende bug-rapporten doormaken voordat het normaliseert. Anderen beweren dat AI-geschreven code uiteindelijk veiliger zal zijn dan menselijke code. Ik ben daar niet overtuigd van.

Hoewel ik geen voorspellingen doe, is het duidelijk dat de software-industrie en open source zullen veranderen. Het is onze collectieve verantwoordelijkheid om ervoor te zorgen dat deze verandering ten goede komt aan iedereen, en niet alleen aan private corporaties en speciale belangen.

Updates

Dit is een ontwikkelingsverhaal; updates worden hier toegevoegd.

***

Voetnoten

1. Er is discussie over de vraag of er daadwerkelijk werkende exploits waren vóór de release van de patch.
2. Disclaimer: ik werk (deels) voor de Britse overheid.
3. GitLab gebruikt CVSS 3.1 terwijl PHP CVSS 4.0 gebruikt; deze metrieken zijn niet direct vergelijkbaar.
4. (Geen inhoudelijke toevoeging in origineel).
5. Indien deze criminelen ooit berecht worden, stel ik voor dat hun zwaarste straf is voor "misdaden tegen woordspelingen".
6. Ter verduidelijking: er is geen bewijs dat deze groep Russisch is. Vroeger kon je Russische phishingcampagnes herkennen aan grammaticale eigenaardigheden, maar door AI is dat charmante kenmerk verdwenen.
7. Verwijzing naar een incident waarbij Pete Hegseth per ongeluk details over militaire aanvallen in Jemen naar The Atlantic stuurde.