Kort gezegd: Tot de bewezen PHP2Shell-feiten behoren de twee CVE-nummers, de beoordeling met CVSS v4.0 9.2, de verholpen PHP-versies en de tussentijdse maatregelen van php.net. Ook bewezen is het waarschuwingsniveau Oranje van het BSI (de Duitse federale dienst voor informatiebeveiliging). Niet bewezen zijn een beoordeling met CVSS 10, bevestigde geslaagde aanvallen op grote schaal en een lijst met herkenningskenmerken. Wie deze drie niveaus scheidt, neemt betere beslissingen.
Waarom een factcheck over PHP2Shell nodig is
Nauwelijks een beveiligingslek van de afgelopen jaren heeft zo snel zoveel krantenkoppen opgeleverd. Al voordat het PHP-team op 21 oktober 2026 de updates publiceerde, circuleerden volgens berichten forumbijdragen, schermafbeeldingen en vermeende details. Daarna volgden overheidswaarschuwingen, blogs van fabrikanten, tellingen van blootgestelde servers en een stortvloed aan tips.
Voor beheerders betekent dat: niet elk cijfer en niet elk advies heeft dezelfde kwaliteit. Een deel komt uit primaire bronnen, een deel uit serieuze berichtgeving, een deel uit speculatie. Dit artikel sorteert wat u voor uw beslissingen als vaststaand kunt gebruiken. De basis van het lek zelf legt de pagina Wat is PHP2Shell? uit.
Welk gewicht welke bronnen hebben
Een eenvoudige rangorde helpt bij het lezen van elke melding:
- php.net: Het PHP-project is de primaire bron voor CVE-nummers, beoordelingen, getroffen uitvoeringsmodi, verholpen versies en tussentijdse maatregelen. Hoe het project beveiligingsmeldingen in het algemeen behandelt, beschrijft onze bijdrage over het PHP-beveiligingsproces.
- Overheden: Het BSI levert de inschatting van de situatie in Duitsland en aanbevelingen voor maatregelen, CERT-EU en CERT-Bund (het Duitse overheids-CERT) vullen aan.
- Distributies en aanbieders: Debian, Ubuntu, Red Hat, hostingproviders en platformdiensten zeggen alleen bindend iets over hun eigen pakketten en diensten.
- Beveiligingsbedrijven: Cloudflare, Unit 42, CybelAngel en anderen rapporteren op basis van eigen metingen. Waardevol, maar telkens met een eigen methode.
- Media en sociale netwerken: Goed voor het tempo, zwak in de details. Uitspraken van daar hebben bevestiging van hoger op de lijst nodig.
Bewezen, gemeld, onbewezen: het overzicht
De volgende tabel rangschikt de meest voorkomende uitspraken. „Bewezen” betekent: primaire bron of overheid. „Gemeld” betekent: uit media of opgaven van fabrikanten, niet onafhankelijk bevestigd.
| Uitspraak | Inschatting | Grondslag |
|---|---|---|
| Twee lekken, CVE-2026-109618 en CVE-2026-109619 | bewezen | php.net |
| Beoordeling CVSS v4.0 9.2, kritiek | bewezen | php.net |
| Beoordeling CVSS 10 | niet houdbaar | volgens berichten uit een forumbijdrage vóór de melding |
| Verholpen in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | bewezen | php.net |
| mod_php met het hoogste risico, exploit getoond vóór toepassingscode | bewezen | php.net |
| Bijna alle versies tot en met PHP 5.4 getroffen | gemeld | vakpers |
| Eerste aanvalspoging op 17 oktober | gemeld | mediaberichten onder verwijzing naar Amazon |
| Meer dan 22,6 mln. blootgestelde instanties | gemeld | Unit 42, volgens TechTarget |
| Geslaagde aanvallen op grote schaal | onbewezen | volgens het BSI aanvankelijk niet bekend |
| Bevestigde Indicators of Compromise | bestaan niet | geen publicatie |
| Tussentijdse maatregelen beschermen volledig | onjuist | php.net noemt ze uitdrukkelijk onvolledig |
Opvallend is hoe snel cijfers een eigen leven gaan leiden. De beoordeling 10.0 uit de forumbijdrage dook nog dagen later op in bijdragen, hoewel het PHP-team allang 9.2 had gepubliceerd.
Waar de onzekerheid echt zit
De grootste open vraag is niet technisch maar tijdelijk: wat is er gebeurd tussen de eerste gemelde aanvalspoging en de patch op afzonderlijke servers? Daarop bestaat geen algemeen antwoord. Cloudflare en Patchstack meldden aanvalspogingen, watchTowr heeft CVE-2026-109618 naar eigen zeggen nagebootst. Huntress zag op het moment van zijn melding juist geen aanvallen in partneromgevingen.
Deze uitspraken spreken elkaar niet tegen. Ze beschrijven verschillende uitsneden: een grote proxydienst, een beveiligingsbedrijf voor plug-ins, een onderzoeksteam en een bedrijf met een eigen klantenbestand. Een totaalbeeld ontstaat er niet uit.
Hetzelfde geldt voor de vraag welke versies getroffen zijn. Voor 8.2 tot en met 8.5 is de situatie duidelijk. Voor oudere takken bestaan minimale broncode-backports voor 7.4, 8.0 en 8.1, maar geen officiële releases. Wat daarvoor ligt, is volgens de vakpers vrijwel overal getroffen. Voor uw planning maakt dat nauwelijks verschil: een server met PHP 8.1 of ouder zonder bevestigde backport moet als kwetsbaar worden behandeld.
Het ontbreken van bewijs voor aanvallen is geen bewijs van veiligheid. Omdat er geen bevestigde herkenningskenmerken zijn, is een aanval op een afzonderlijke server alleen via een controle van het gedrag in te schatten, niet via een lijst.
Wat u hieruit afleidt voor uw servers
Uit de bewezen feiten volgen enkele duidelijke stappen. Uit de onbewezen volgt vooral voorzichtigheid.
- Patchstatus controleren: verholpen versie of door de aanbieder bevestigde backport. Het weergegeven versienummer alleen volstaat niet.
- Alle PHP-processen herstarten: Nieuwe bestanden werken pas als er geen oude processen meer draaien.
- Logs vanaf 20 oktober veiligstellen: De vakpers raadt dit aan, zodat een latere controle mogelijk blijft.
- Op sporen controleren: Nieuwe PHP-bestanden in uploadmappen, onbekende cronjobs, webserverprocessen met shell. De pagina Ben ik al gecompromitteerd? leidt u door de controle.
- Adviezen natrekken: Tips uit forums en sociale netwerken alleen toepassen als ze terug te voeren zijn op php.net of een overheid. Welke aanbevelingen momenteel schade doen, verzamelt de bijdrage Gevaarlijke valse tips over PHP2Shell.
Ook voor de interne communicatie helpt dezelfde scheiding. Wie het management „bewezen”, „gemeld” en „open” gescheiden voorlegt, vermijdt zowel alarmisme als valse geruststelling.
Hoe helpt PHP SOS concreet?
- Situatie voor uw systemen: Wij zetten de bewezen feiten om naar uw servers en scheiden in de documentatie wat gemeten, wat gemeld en wat open is.
- Patch en bewijs: Wij controleren de pakketstatus en de herstart van elke PHP-service en leggen dat schriftelijk vast.
- Sporencontrole: Wij stellen logs vanaf 20 oktober veilig en zoeken naar afwijkend gedrag, tot het incident is afgesloten en gedocumenteerd.
- Doorlopende beoordeling: Nieuwe meldingen beoordelen wij voor u, voordat er maatregelen uit voortkomen.
Het verloop beschrijft de PHP2Shell-noodhulp.
Conclusie
PHP2Shell is ernstig, en dat is goed onderbouwd. Juist daarom loont een nuchtere blik: de primaire bronnen volstaan voor alle belangrijke beslissingen. Wat daarbuiten rondgaat, is vaak sneller dan nauwkeurig. Patchen, herstarten, logs veiligstellen en op sporen controleren blijft het antwoord, ongeacht welk cijfer er op dat moment rondgaat.
Veelgestelde vragen
Is PHP2Shell beoordeeld met CVSS 10?
Nee. Het cijfer 10 komt volgens berichten uit een forumbijdrage die al rondging vóór de officiële melding. Het PHP-team beoordeelt beide lekken met CVSS v4.0 9.2. Dat valt nog steeds in de categorie kritiek.
Is er een lijst met herkenningskenmerken voor PHP2Shell-aanvallen?
Tot nu toe niet. Er zijn geen gepubliceerde, bevestigde Indicators of Compromise. Wie wil controleren of een server getroffen was, moet letten op afwijkend gedrag, bijvoorbeeld webserverprocessen die een shell starten of nieuwe PHP-bestanden in uploadmappen.
Welke bron is bij PHP2Shell het betrouwbaarst?
Voor de technische feiten de meldingen op php.net, voor de inschatting van de situatie in Duitsland het BSI. Mediaberichten en blogs van fabrikanten vullen het beeld aan, maar moeten als berichten worden aangemerkt en naast de primaire bron worden gelezen.
Zijn echt alle PHP-versies vanaf PHP 5 getroffen?
Bewezen is de situatie voor de takken 8.2 tot en met 8.5, waarvoor updates bestaan. Volgens de vakpers zijn bijna alle versies tot en met PHP 5.4 getroffen; CERT-EU achtte volgens berichten versies vanaf PHP 5 mogelijk. Voor oudere versies zijn er geen officiële updates, dus u moet ze in elk geval als kwetsbaar behandelen.