# PHP2Shell: wat het PHP-lek betekent voor je website | Fokuus

[Home](https://fokuus.be/) [Blog](https://fokuus.be/blog/) PHP2Shell: wat het PHP-lek betekent voor je website 

# PHP2Shell: wat het PHP-lek betekent voor je website

PHP2Shell zijn twee kritieke lekken in PHP, de taal onder WordPress. Wat er uur per uur gebeurde, wie wat zag van misbruik en welke versies de fix bevatten.

[Anton Pycarelle](https://fokuus.be/about/)  22 oktober 20266 min leestijd

## In dit artikel

- [Wat is PHP2Shell?](https://fokuus.be/#wat-is-php2shell)
- [Van uitgelekt nummer tot fix](https://fokuus.be/#van-uitgelekt-nummer-tot-fix)
- [Wie zag welk misbruik, en wanneer](https://fokuus.be/#wie-zag-welk-misbruik-en-wanneer)
- [Wat overheden en WordPress.org adviseren](https://fokuus.be/#wat-overheden-en-wordpress-org-adviseren)
- [Oude PHP-versies zijn het moeilijkste geval](https://fokuus.be/#oude-php-versies-zijn-het-moeilijkste-geval)
- [Wie werkt bij jou PHP bij?](https://fokuus.be/#wie-werkt-bij-jou-php-bij)

Een lek in PHP los je niet op met een WordPress-update. Het zit een verdieping lager, in de software op de server, en dus moet wie die server beheert in actie komen: bij de meeste kmo's de hostingpartij, niet de eigenaar van de site. Dat is de kern van PHP2Shell, het PHP-lek waarvoor in België Smartschool, de VDAB, de FOD Financiën en een reeks ziekenhuizen hun website uit voorzorg offline haalden, [meldde VRT NWS](https://www.vrt.be/vrtnws/nl/2026/10/21/cyberbeveiliger-ziet-eerste-aanvallen-rond-kwetsbaarheden-in-pop/) .

## Wat is PHP2Shell?

PHP2Shell is de bijnaam voor twee kritieke lekken in PHP zelf, CVE-2026-109618 en CVE-2026-109619, waardoor iemand zonder in te loggen eigen code kan laten uitvoeren op een webserver met PHP. Het PHP-project bracht er op 21 oktober 2026 [dringende updates](https://www.php.net/archive/2026.php#2026-10-21-5)  voor uit en gaf beide lekken in zijn [vooraankondiging](https://www.php.net/archive/2026.php#2026-10-20-1)  een ernstscore van 9,2 op 10.

PHP is de programmeertaal die op de server een pagina opbouwt zodra iemand ze opvraagt. Volgens [W3Techs](https://w3techs.com/technologies/details/pl-php)  draait 69,3 procent van de websites waarvan de servertaal bekend is op PHP (meting 22 oktober 2026). Daaronder zit WordPress, goed voor [39,6 procent van alle websites](https://w3techs.com/technologies/details/cm-wordpress)  en volgens de [eigen systeemvereisten](https://wordpress.org/about/requirements/)  afhankelijk van PHP.

In gewone taal: bij het eerste lek valt PHP midden in een verzoek zonder geheugen en behandelt het daarna halfafgewerkte gegevens als geldig. Bij het tweede blijven restjes van een vorig verzoek hangen, die een volgend verzoek weer oppikt. Allebei kunnen ze eindigen met code van een buitenstaander op je server. Bij de gevaarlijkste opstelling, Apache met mod_php, kan volgens het PHP-team een verzoek zonder login de aanval al starten, nog voor je website-software iets doet.

## Van uitgelekt nummer tot fix

Normaal blijft zo'n lek geheim tot de oplossing klaar is. Linux-distributies krijgen de fix vooraf, zodat hun gebruikers meteen kunnen bijwerken. Dat liep deze keer mis, [schrijft de PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/)  zelf.

Op 20 oktober rond 17 uur Belgische tijd doken de CVE-nummers online op, nog zonder technische details. Om 21.30 uur vervroegde PHP de release van 22 naar 21 oktober. Diezelfde avond zette Calif, een van de bedrijven die de lekken meldden, per vergissing een video van een werkende aanval online. Op 21 oktober om 9.41 uur publiceerde Chainguard de fix, ruim zes uur voor het afgesproken tijdstip; volgens de PHP Foundation konden aanvallers hem zo al bestuderen. De updates zelf kwamen rond 15.30 uur, volgens [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/) .

Tussen het uitlekken van de nummers en de fix zat bijna een dag, en Amazon zag de eerste aanvalspoging al vier dagen eerder.

## Wie zag welk misbruik, en wanneer

Eén onderscheid eerst: een poging is geen inbraak. Veel meldingen komen van lokservers, nepservers die aanvallers aantrekken. Een poging daarop bewijst dat iemand het probeert, niet dat het bij echte sites lukt.

[Amazon](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)  zag op 17 oktober een eerste poging op zo'n lokserver, zonder te weten hoe de aanvaller toen al aan informatie kwam. Op 21 oktober tussen 4 en 10 uur volgden er meer, van meerdere aanvallers; of die bij echte systemen gelukt zouden zijn, is volgens Amazon onduidelijk. Het Nederlandse NCSC schreef op 21 oktober, nog voor de patch, dat er [publieke proof-of-concept-code](https://www.ncsc.nl/alerts/ernstige-kwetsbaarheden-in-php-bereid-je-voor-op-patchen)  was, maar zag zelf geen actief misbruik. [Cloudflare](https://blog.cloudflare.com/php-vulnerabilities-waf-protection) , met filterregels actief vanaf 5.02 uur, zag wel aanvalsverkeer naar zijn klanten.

Bij de release vond het PHP-team tussen de publieke proof-of-concepts geen enkele die werkte. Dat sluit werkende aanvallen niet uit: Calif toonde er een in zijn video, en [watchTowr](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/)  zegt beide lekken zelf nagebouwd te hebben. [CISA](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) , het Amerikaanse cyberagentschap, had bij zijn waarschuwing van 21 oktober nog geen misbruik vastgesteld; CERT-EU schatte de kans erop hoger omdat er proof-of-concepts circuleerden. Intussen ziet watchTowr actieve aanvalspogingen op beide lekken en spreekt Amazon van breed misbruik.

Mijn lezing: dat er geprobeerd wordt, staat vast; een publiek bevestigde geslaagde inbraak via PHP2Shell vond ik in deze bronnen niet. Voor een kmo met een PHP-site betekent dat twee dingen. Wachten tot er slachtoffers in het nieuws komen, heeft geen zin: Amazon raadt aan sporen te zoeken vanaf 17 oktober, niet vanaf de bekendmaking. En paniek helpt evenmin, want de enige volledige oplossing ligt klaar: PHP bijwerken.

## Wat overheden en WordPress.org adviseren

Over één ding zijn ze het eens: werk PHP nu bij. Lukt dat niet meteen, dan verschilt hun advies. CISA en het [Nederlandse NCSC](https://www.ncsc.nl/alerts/kwetsbaarheden-php-patches-beschikbaar-update-nu)  zijn het strengst. Wie niet meteen kan bijwerken of nog op 8.1 of ouder zit, moet volgens CISA zijn PHP-systemen offline halen tot ze bijgewerkt zijn. Het NCSC schrijft: "Zolang systemen niet zijn bijgewerkt, is het nodig deze uit voorzorg offline te houden." Het [Britse NCSC](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)  verwijst eerst naar de tijdelijke maatregelen van PHP en vraagt pas als die niet lukken om offline halen te overwegen. CERT-EU vraagt organisaties te overwegen om internetgerichte toepassingen af te schermen.

Moet je WordPress updaten voor dit lek? Nee. [WordPress.org](https://wordpress.org/news/2026/10/critical-php-security-release/)  schreef op 21 oktober dat er voor deze lekken geen WordPress-update nodig of gepland is, omdat ze in PHP zitten, en verwijst voor de PHP-update naar je webhost. Ook een plugin of thema bijwerken lost het niet op, benadrukt Cloudflare.

## Oude PHP-versies zijn het moeilijkste geval

Welke PHP-versies zijn veilig? Beschermd tegen PHP2Shell ben je met de gepatchte versie van je eigen reeks of een hoger nummer binnen die reeks: 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Wie 8.3.20 draait, zit dus niet goed, ook al is dat nummer hoger dan 8.2.35, tenzij je leverancier de fix zelf in die versie inbouwde (zie hieronder). PHP 8.1 en ouder krijgen van het PHP-project geen nieuwe release, hoogstens een minimale broncodepatch (voor 7.4, 8.0 en 8.1) voor wie PHP zelf compileert. En 8.2 krijgt na 31 december 2026 [geen beveiligingsfixes meer](https://www.php.net/supported-versions.php) .

Dat raakt veel sites: volgens W3Techs draait meer dan een derde van de websites met PHP nog op versie 7 of 5 (meting 22 oktober 2026). Een oud versienummer is wel niet automatisch kwetsbaar: Sommige Linux-distributies, LTS-leveranciers en hosts bouwen de fix ook in oudere versies in; php.net verwijst daarvoor naar je leverancier. Of dat bij jou gebeurd is, weet alleen wie je PHP beheert.

## Wie werkt bij jou PHP bij?

Belangrijker dan alle technische details is die ene vraag. Weet niemand bij jou het antwoord, dan is dat het eigenlijke probleem, los van dit lek. De meeste sites die wij bouwen, zijn statisch en draaien op Netlify zonder PHP op de webserver; waarom we daarvoor kiezen, lees je in [onze post over onderhoud](https://fokuus.be/blog/website-onderhoud-hoeveel-nodig/) .

Heb je wel een PHP- of WordPress-site: [ons stappenplan](https://fokuus.be/blog/website-getroffen-php-lek/)  toont hoe je nagaat of je site geraakt is, [onze checklist](https://fokuus.be/blog/php-wordpress-site-beveiligen/)  wat je structureel regelt. Wil je dat wij meekijken, dan kan dat via [hosting en onderhoud](https://fokuus.be/hosting-onderhoud/) .

PHP WordPress Websitebeveiliging Hosting

Delen [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ffokuus.be%2Fblog%2Fphp2shell-php-lek%2F) [WhatsApp](https://wa.me/?text=PHP2Shell%3A%20wat%20het%20PHP-lek%20betekent%20voor%20je%20website%20https%3A%2F%2Ffokuus.be%2Fblog%2Fphp2shell-php-lek%2F) [E-mail](mailto:?subject=PHP2Shell%3A%20wat%20het%20PHP-lek%20betekent%20voor%20je%20website&body=https%3A%2F%2Ffokuus.be%2Fblog%2Fphp2shell-php-lek%2F)

## Schrijf je in voor nieuws.

Nieuwe artikelen en updates van Fokuus in je mailbox. Je kunt je op elk moment uitschrijven.

## Anton Pycarelle

Oprichter van Fokuus

Anton bouwt en optimaliseert websites voor Belgische kmo’s vanuit Kortrijk. Hij schrijft over keuzes en ervaringen uit echte projecten.

[Meer over Fokuus](https://fokuus.be/about/)

## Verder lezen.

[Alle artikelen](https://fokuus.be/blog/)

Onderhoud & Techniek · 7 min leestijd 

### WordPress- of PHP-site beveiligen: 10 dingen om op te letten

WordPress- of PHP-site beveiligen: tien punten, van een ondersteunde PHP-versie tot een noodplan, en bij elk punt wie het doet: jij, je webbouwer of je host.

[Onderhoud & Techniek · 7 min leestijdWordPress- of PHP-site beveiligen: 10 dingen om op te lettenWordPress- of PHP-site beveiligen: tien punten, van een ondersteunde PHP-versie tot een noodplan, en bij elk punt wie het doet: jij, je webbouwer of je host.](https://fokuus.be/blog/php-wordpress-site-beveiligen/)

Onderhoud & Techniek · 7 min leestijd 

### Is mijn website getroffen door het PHP-lek? Zo check je het

Raakt het PHP-lek van oktober 2026 jouw website? In vijf stappen check je of je site op PHP draait, welke versie, of je host al patchte en of er sporen zijn.

[Onderhoud & Techniek · 7 min leestijdIs mijn website getroffen door het PHP-lek? Zo check je hetRaakt het PHP-lek van oktober 2026 jouw website? In vijf stappen check je of je site op PHP draait, welke versie, of je host al patchte en of er sporen zijn.](https://fokuus.be/blog/website-getroffen-php-lek/)

[Bron](https://fokuus.be/blog/php2shell-php-lek/) · [Agentdocumentatie](https://fokuus.be/developers/)
