PHP waarschuwt voor twee ernstige bugs die makkelijk uit te buiten lijken

De makers van PHP waarschuwen website- en softwarebeheerders voor twee ernstige kwetsbaarheden in PHP. Het gaat om remote code execution-bugs die eenvoudig kunnen worden uitgebuit. PHP wil zelf later op woensdag details naar buiten brengen, maar er lijkt inmiddels een proof-of-concept openbaar beschikbaar te zijn.

De makers van PHP waarschuwen zelf voor een komende beveiligingsrelease die twee ernstige kwetsbaarheden verhelpt. Het gaat om bugs met een score van 9.2 op het Common Vulnerability Scoring System (CVSS). CVSS-scores lopen van 1 tot 10 en geven aan hoe groot de impact van een bug is en hoe makkelijk het is die uit te buiten. PHP wil om 16.00 uur Nederlandse tijd meer details bekendmaken.

Aanvankelijk wilde PHP de bugs op donderdag bekendmaken. Eerder deze week lekte echter al informatie over de bugfixes uit op Hacker News, in een post die inmiddels verwijderd is. PHP besloot daarop de bugs eerder bekend te maken.

Proof of concept

Inmiddels is echter wel iets meer duidelijk over de bugs. Beveiligingsonderzoekers van Watchtowr zeggen dat het om de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 gaat. Officieel zijn er nog geen technische details bekend, maar er gaat inmiddels wel een proof of concept rond waarin te zien is hoe een aanvaller de loginfunctionaliteit op websites met contentmanagementsystemen (cms'en) als Joomla en WordPress omzeilt. Ook kan de aanvaller het wachtwoord uit een Symfony-framework achterhalen.

PHP2Shell

De proof-of-conceptvideo noemt de bug PHP2Shell en laat zien dat hij met slechts een eenvoudig Python-script en zonder veel verdere tussenstappen werkt. De bug is ook ernstig doordat PHP in veel applicaties wordt gebruikt, zoals cms-tools.

Mogelijk zijn ook veel PHP-versies kwetsbaar. Volgens Watchtowr zitten de bugs in alle versies sinds PHP 5.

Beheerders doen er volgens Watchtowr en andere beveiligingsbedrijven goed aan te inventariseren welke versies van PHP ze in welke applicaties gebruiken. Ze zouden daarnaast een plan moeten maken voor een snelle upgrade later op de dag, als PHP met een officiële patch komt.

Reacties (30)

[ApexAlpha]

Hij staat hier al: https://jackalsyn.com/posts/php-up-2026.html
Op Hckrnews bevestigen comments dat dit werkt.

Wij gaan nu iedereen met PHP in hun team wakker bellen als ze dat nog niet zijn. Eerst off-line, zien straks wel.

Ik gok dat over een paar uurtjes de helft van alle PHP sites, vooral Wordpressjes totaal gepwnd zal zijn.

Man man man, er was vroeger nog een soort code rondom deze leaks. Nu racen ze wie het snelst een werkbare exploit kan uploaden...

Succes allemaal vandaag.

[Reactie gewijzigd door ApexAlpha op 21 oktober 2026 08:09]

[xxs]

Geen paniek, gewoon de stekker eruit en lekker een weekje vaag blijven wat er aan de hand is. AH zit dat zo?

Maar zonder gekheid, kijk even wat de dag gaat brengen vaak is het zo dat bij een dergelijke groot issue er snel mitigerende maatregelen voorgesteld worden. Of zelfs al een patch.

Goede monitoring is wel van belang natuurlijk.

[Reactie gewijzigd door xxs op 21 oktober 2026 08:33]

[ApexAlpha]

Patches komen vanmiddag 4 uur NL tijd.

Dat is nog 8 uur, dan nog installeren en testen of het werkt. Wij gaan het risico niet lopen. Aan jezelf uiteraard.

[xxs]

PHP wil om 16.00 uur Nederlandse tijd meer details bekendmaken.

Heb jij een andere bron dat er om 16:00 al patches komen?

[jb044]

Op zich wel blij met het container tijdperk, daarvoor was het in mijn geval ook wel erg veel gedoe om alles maar een beetje met elkaar samen te laten werken, zeker voor wat betreft een beetje fatsoenlijk package management. Maar dit is echt wel een dingetje en echt niet grappig

[gatlarf]

Het lastige aan containers is nu dus ook wel dat je overgeleverd bent aan de genade van de maintainer van een container om een versie te releasen waarin de patch zit… Gelukkig geeft Wordpress bijvoorbeeld aan dat de container niet voor productie geschikt is. Maar hoeveel sites zouden er draaien in zo’n container en vrolijk aan het boze internet hangen?

Bij een Wordpress bijvoorbeeld zal dit vermoedelijk snel gepatched zijn, maar er zijn vele containers die van mindere goden afhangen vrees ik.

[jb044]

Yup, precies dat. Het is gelukkig ook niet zo dat dit soort dingen op php niveau ons om de oren vliegen. Maar nu dus wel even.

[Glashelder]

Je kan een container ook gewoon zelf patchen hoor..

[jb044]

Ja dat is wel een goede. Bij mij is de scope redelijk beperkt, maar de meeste containers zullen debian'ish of alpine zijn. Dus een:

apt-get update && apt-get upgrade

of

apk update

Zou een workaround kunnen zijn. Desnoods in een simpele Dockerfile om het pertistent te maken.

[Glashelder]

Ligt het aan mij of heb je eigenlijk weinig keus behalve je PHP applicaties offline te halen totdat er een patch is?

[Saven]

Daar lijkt het wel op. Er werd een mitigatie geopperd maar volgens ingewijden is de enige oplossing een update. Ben benieuwd of Cloudflare een soort bescherming kan aanbieden.

[Little Penguin]

Dat is een goede vraag, maar is afhankelijk van hoe de exploit werkt. Als dat een bepaald patroon volgt is er misschien wel bescherming mogelijk.

Mocht het zo zijn dat specifiek de login-pagina's aangevallen worden dan zouden deze nartuurlijk wat gemakkelijker afgeschermd kunnen worden, eventueel met ACL blocking op IP, een oplossing met extra inloggen op HTTP-niveau (Authorization header) of (veel geavanceerder) het gebruik van client-certificaten.

[Christoxz]

Er gaat rond dat `session.upload_progress.enabled = Off` in php.ini + multipart requests weigeren een maatregel kan zijn, maar het is allemaal niet duidelijk of dat het volledig waterdicht maakt.

[Whisper380]

In sommige gevallen ben je afhankelijk van de hosting provider welke PHP versie je mag/kan gebruiken/beschikbaar is. Ik hoop dat deze ook snel de updates beschikbaar stellen.

[Falcon]

Er is nog geen patch beschikbaar

[MrMaxus]

Vandaag: https://www.php.net/archive/2026.php#2026-10-20-1

[The Zep Man]

Om preciezer te zijn, vandaag om 16:00 CEST.

[EricBruggema]

"slechts een eenvoudig Python-script"

Ik ben benieuwd hoe de auteur kan zeggen dat het een eenvoudig python scriptje is? of staat dat ergens te lezen? want naar mijn inziens is het niet echt een 'eenvoudig' script, want een eenvoudig scriptje kan bijna iedereen schrijven.

Ben benieuwd.

[CH4OS]

Er is proof of concept code beschikbaar, gelinkt in het artikel.

[PolarBear]

Dat is een filmpje niet een script

[newuzer]

Mogelijke mitigatie (maar niet 100% confirmed):
https://www.behindtheconsole.com/2026/10/21/patch-your-php-pre-2026-10-20/

[frackleboom]

Nee. Dit is geen mitigatie. Schakel multipart-uploads waar mogelijk volledig uit, of zet je applicatie uit totdat je kunt patchen. Zie ook: dit advies.

[RVervuurt]

Ze updaten alleen PHP 8 heb ik begrepen, maar een beetje host heeft toch wel php 7.4 uitgefaseerd, gezien die al in november 2022 EOL was? Zelfs 8.0 en 8.1 zijn al EOL zie ik.

Hoeveel zou het helpen om niet geraakt te worden, als je je login-pagina niet op default hebt staan? Dus ipv /wp-admin heb je iets als /loginpagina ofzo?

[Reactie gewijzigd door RVervuurt op 21 oktober 2026 08:22]

[gewoontelefoon]

Ooops ik heb nog wat sites draaien op php7.4 heb al geprobeerd om ze over te zetten maar hee veel gedoe en het lukt niet. We wachten maar af. pffff

[RVervuurt]

"We wachten maar af" gaat je niet helpen hoor. Ik zou actief die projecten offline halen OF actief gaan werken naar een upgrade naar minstens 8.3.

[CH4OS]

Als ik https://www.huntress.com/...tical-php-vulnerabilities goed begrijp, gaat het om de interpreter en niet zozeer de gebruikte webapplicatie die vervolgens een shell (bash, PowerShell, you name it) kan opstarten en in die shell vervolgens een bestand met code laat uitvoeren, dat weggeschreven wordt naar de eerste map die het vindt met schrijfrechten, bijvoorbeeld /tmp onder Linux.

[Sponge]

Weet nog niet precies wat de consequenties zijn en wat nou de exacte vereisten zijn om dit te laten werken (een losse POST?)... maar zojuist toch maar de firewall regels voor 80 en 443 aangepast om straks eens even beter te kijken naar hoe en wat...

Nu ook maar hopen dat hosting partijen een beetje opletten.