Wat we nu weten over PHP2Shell, de twee kwetsbaarheden in scriptingtaal PHP

Wat we nu weten over PHP2Shell, de twee kwetsbaarheden in scriptingtaal PHP

Het internet staat op scherp door de plotse en vage bekendmaking van twee kritieke kwetsbaarheden in PHP. Die scriptingtaal is naar schatting in gebruik bij bijna 70 procent van alle websites wereldwijd, maar draait ook op andere apparaten. Patches zijn nu beschikbaar. Sites die uit voorzorg offline zijn gegaan, zoals Tweakers, komen nu weer online.

Aanvallers kunnen via de twee kwetsbaarheden op afstand websites aanpassen en mogelijk eigen code uitvoeren op servers. Patches zouden donderdag komen, maar informatie over de kwetsbaarheden lekte vroegtijdig uit. Daarom beloofde het PHP-ontwikkelteam vanmiddag om 16.00 uur meer informatie te geven en patches uit te brengen. Die zijn iets eerder uitgekomen voor de momenteel ondersteunde versies van de scriptingtaal. Wat weten we op de dag van de PHPocalypse?

Wat is PHP?

PHP is een veelzijdige en populaire scriptingtaal voor algemeen gebruik. Het werd in de jaren negentig ontwikkeld voor persoonlijke homepages. Sindsdien is het echter ingezet voor veel meer onlinetoepassingen, waaronder complexe websites, webapps en relatief eenvoudige beheerinterfaces voor uiteenlopende apparaten.

PHP-icoon. Bron: PHP.net, Vincent Pontier

De opensourcetaal laat websites dynamische pagina's serveren aan bezoekers. Scripts geschreven in PHP draaien op webservers. Ontwikkelaars kunnen zogeheten PHP-frameworks gebruiken om hun code te schrijven. Die tools verzorgen basale mogelijkheden op websites, zoals inloggen voor gebruikers en beheer van de websoftware. Daaronder valt ook beveiliging van de geschreven code, zoals van de beschikbare functies en al dan niet geïnstalleerde updates.

Waarom is de impact zo groot?

PHP wordt massaal gebruikt. Volgens gebruiksmetingen van webmonitor W3Techs draait PHP op 69,3 procent van alle websites wereldwijd. Daarbij vormt PHP de basis voor contentmanagementsystemen zoals WordPress, waarop bijna 40 procent van de sites draait. Ook websoftware als Joomla, Drupal, Magento, MediaWiki, phpBB, Laravel en Symfony gebruiken PHP.

Het op PHP gebaseerde WordPress draait op ongeveer 40 procent van alle websites. Bron: WordPress

PHP's marktaandeel van bijna 70 procent geldt voor openbare websites, maar de veelgebruikte scriptingtaal draait ook op andere plekken. PHP doet namelijk ook dienst in webinterfaces voor apparaten. Denk aan taakgerichte apparaten die een eigen webserver draaien waarmee die systemen op afstand zijn te beheren. Als zulke beheerinterfaces via internet toegankelijk zijn, kan PHP2Shell een kritiek probleem zijn voor deze systemen.

Verder kunnen internet-of-thingsapparaten, microcomputers zoals de Raspberry Pi en wifirouters technisch gezien ook PHP draaien. Vaak moeten gebruikers die populaire webtaal wel zelf inschakelen of installeren. Op wifirouters kan eerst nog de installatie van alternatieve firmware nodig zijn, zoals OpenWrt. Verder moet voor PHP-misbruik zo'n PHP-draaiende webserver op consumentenapparatuur dan wel vanaf internet benaderbaar zijn.

PHP is dus niet standaard overal aanwezig, maar toch kan het meer in gebruik zijn dan het marktaandeel van bijna 70 procent aangeeft.

Wat zijn de risico's?

De voortijdig uitgelekte informatie over de twee kritieke kwetsbaarheden veroorzaakte flinke zorgen. De twee gaten (CVE-2026-109618 en CVE-2026-109619) krijgen volgens versie 4.0 van het Common Vulnerability Scoring System (CVSS) een score van 9,2 op een schaal tot 10. Dat hoge cijfer is gebaseerd op hoe ernstig een kwetsbaarheid is en hoe makkelijk die valt uit te buiten. Verder zouden de twee gaten al sinds versie 5 in PHP zitten, specifiek: sinds versie 5.4.0. Die release kwam in maart 2012 uit.

De uitgelekte informatie over de PHP-kwetsbaarheden heeft al geleid tot exploitcode, waarmee de gaten zijn te misbruiken. Een online gepubliceerde video toont dat een script draaien op inlogpagina's van bekende contentmanagementsystemen toegang geeft tot websites. Een kwaadwillende kan zo eigen webpagina's publiceren, waardoor die malware kunnen verspreiden. Volgens rondgaande berichten kan PHP2Shell ook de mogelijkheid geven om eigen code te draaien op kwetsbare servers.

De ontwikkelaars van PHP zijn genoodzaakt om hun patches eerder uit te brengen. Oorspronkelijk was het plan om de updates donderdag uit te brengen, met dan pas informatie over de te verhelpen kwetsbaarheden. Doordat die informatie uitlekte, zijn de patches vandaag al uitgekomen. Dit gebeurde iets voor 16.00 uur.

De makers van PHP gaven vanmorgen al aan dat ze hun release mogelijk eerder zouden uitbrengen. Dit zouden ze doen als details over de kwetsbaarheden openbaar zouden worden of als er bewijs zou zijn van actief misbruik. In de praktijk voeren kwaadwillenden al scans uit op sites zoals Tweakers.

Wat valt er nu tegen te doen?

Beheerders moeten zo snel mogelijk de patches installeren. Reguliere beveiligingsmaatregelen zoals monitoring kunnen eventueel misbruik aan het licht brengen, maar niet per se voorkomen. In de loop van vandaag gingen online verschillende beveiligingsadviezen rond, maar die zouden niet afdoende zijn.

Een genoemde mitigeringsmaatregel zou zijn session.upload_progress.enabled uitschakelen. Een bijbehorende tijdelijke workaround was session.use_strict_mode inschakelen. Securityexpert Kevin Beaumont meldde dat de Linux-kernelbeveiligingsmodules AppArmor of Security-Enhanced Linux (SELinux) ook bescherming bieden tegen misbruik van deze grote PHP-kwetsbaarheden.

Verder zou een van de twee kwetsbaarheden te maken hebben met multipart POST-requests. Voor websites waar uploads in meerdere delen niet nodig zijn, kunnen beheerders zulke dataverzoeken blokkeren en daarmee kwetsbare systemen beschermen. Mogelijk kunnen ook firewallinstellingen en contentdistributiediensten, zoals Akamai en Cloudflare, helpen om PHP-installaties af te schermen tegen kwaadwillige dataverzoeken. Aanvallers kunnen met zulke verzoeken PHP2Shell benutten om binnen te dringen. Een kernontwikkelaar van PHP geeft in een post echter aan dat PHP patchen als enige echt beschermt.

Naast dergelijke mitigatiemogelijkheden is er nog een paardenmiddel: systemen die PHP draaien offline halen. Deze drastische stap geeft vooralsnog de meeste zekerheid van bescherming tegen hackaanvallen. Tegelijkertijd heeft dit natuurlijk vrijwel zeker grote impact op bedrijven, organisaties, klanten, gebruikers en partners. Toch kozen veel sites al hiervoor, waaronder Tweakers en RTL Nieuws. Ook alle Vlaamse overheidswebsites en een aantal Nederlandse, zoals MijnOverheid en DigiD.nl, zijn uit voorzorg offline gegaan.

Verder moeten beheerders van systemen met oudere PHP-versies die upgraden, want de komende patches zijn officieel niet voor oudere releases. Het omslagpunt ligt bij versie 8.2, die officieel nog ondersteuning krijgt tot eind dit jaar.

Kunnen alle PHP-beheerders patchen?

Sites en systemen die recente PHP-versies draaien, krijgen patches. Deze zijn nu te downloaden voor versies 8.2 tot en met 8.5 van de veelgebruikte scriptingtaal. Beheerders moeten deze updates testen en installeren. Het is vooralsnog niet bekend of de patches vanwege de ernst van de kwetsbaarheden ook uitkomen voor PHP-versies van vóór 8.2. Officieel krijgen die oudere PHP-versies namelijk geen ondersteuning meer.

Versie 8.1 is sinds januari dit jaar end-of-life en versie 8.0 sinds eind 2023. Gebruikers van oudere versies krijgen normaliter al het advies om zo snel mogelijk te upgraden, omdat ze anders blootgesteld kunnen zijn aan ongepatchte kwetsbaarheden. Dit is nu dus het geval.

Beeld: Getty Images/Cultura RF

PHP-beheerders hebben ruim de tijd gekregen om te upgraden, want de momenteel ondersteunde versies zijn al jaren beschikbaar. PHP 8.2 kwam in december 2022 uit en versie 8.3 in november 2023. Die twee releases zitten wel in de laatste fase van de ondersteuning, wat betekent dat ze alleen nog beveiligingsupdates krijgen. PHP 8.4 kwam in november 2024 uit en versie 8.5 in november vorig jaar. Die recentste twee releases zitten in de fase van actieve ondersteuning, wat betekent dat ze fixes voor bugs en updates voor beveiligingsproblemen krijgen.

De 8-serie draait volgens metingen van W3Techs op 64,2 procent van de websites die PHP gebruiken. Dit omvat dus ook 8.1 en 8.0, al is het niet duidelijk hoeveel sites precies deze end-of-lifeversies gebruiken. De oudere 7-serie heeft een marktaandeel van 27 procent en de 5-serie draait op 7,7 procent van alle websites die PHP gebruiken.

In totaal draait dus in elk geval 37,7 procent van alle PHP-sites een verouderde versie. Het is de vraag of beheerders van die achterlopende PHP-installaties beschermende maatregelen nemen, zoals workarounds of de sites tijdelijk offline halen.

PHP-versies. Bron: W3Techs

Reacties (147)

[Bedge85]

Ik heb begrepen dat de repository van Ondřej Surý voor Debian en Ubuntu de patches gaat backporten tot en met PHP 5.6. Meer informatie https://deb.sury.org/.

Ondřej Surý is ook maintainer van de officiële packages van PHP in Debian en Ubuntu en het PHP LTS initiatief van Freexian waar je tegen betaling ondersteuning kun krijgen voor verouderde PHP versies die niet meer officieel ondersteund worden door de PHP Foundation.

[tszcheetah]

Die patches lijken ook al online te staan: in https://packages.sury.org/php/pool/main/p/php5.6/ zie je bijv. al versies te zien die vandaag geüpload zijn. Volgens https://codeberg.org/oerdnj/deb.sury.org/issues/145 mogelijk nog niet alles, maar dat is een kwestie van tijd.

[Liveonline]

interessant https://blackoutmap.net/blog/php2shell

[kipkornkoning]

Mooie site is dat zeg.

[Mavamaarten]

Ik spreek je niet lijnrecht tegen, maar in mijn ogen is dit net de meest generieke AI-stijl die je overal tegenkomt. Ik associeer het met: "oei, factchecken wat je leest"

[RubenNL]

Was ook mijn idee toen ik 't zag. Als ik zo'n style zie sluit ik de pagina gelijk. Vaak is het (gedeeltelijk) incorrect.

[Liveonline]

ja ben wel fan van dat soort sites die dat soort zaken op een mooie manier visualiseren

[Nark0tiX]

Weet nou niet of we hier blij mee moeten zijn. Zo blijven partijen updates uitstellen met alle gevolgen van dien.

[CH4OS]

Daarom dat de diensten van Sury veelal niet gratis zijn.

[lenwar]

Goed punt. Deze is nu toevallig gepatched, maar mijn gevoel zegt dat er over de jaren heen wel meer kwetsbaarheden zijn opgedoken, die allemaal niet gepatched zijn.

[Keypunchie]

Dat je shell kunt krijgen, geloof ik wel. Maar dit is toch precies waarom er ook hardening is uitgevonden?

Veel plezier met je shell, maar root heb je niet, syscalls werken niet, geen tooling (want minimaal image) en de interne netwerkpolicy houdt je buiten de rest van het netwerk.

[closefuture]

Veel plezier met je shell, maar root heb je niet, syscalls werken niet, geen tooling (want minimaal image) en de interne netwerkpolicy houdt je buiten de rest van het netwerk.

Als je toegang hebt tot het process waar PHP in draait kun je waarschijnlijk ook gewoon een database connectie e.d. maken. Dat heeft PHP immers nodig om een site te kunnen maken. Dan kun je dus ook alle data kopieeren.

syscalls werken niet

Uiteraard werken syscalls wel. Niet iedere syscall heeft root rechten nodig. Anders kan een proces niet eens een bestand openen om uit te lezen.

[Reactie gewijzigd door closefuture op 21 oktober 2026 16:15]

[RoestVrijStaal]

[...]
Als je toegang hebt tot het process waar PHP in draait kun je waarschijnlijk ook gewoon een database connectie e.d. maken. Dat heeft PHP immers nodig om een site te kunnen maken.
[...]

Hè? Voor een website of applicatie in PHP is geen database vereist.
De opstelling is dan wat anders dan gebruikelijk, maar absoluut niet onmogelijk

[Keypunchie]

Uiteraard werken syscalls wel.

Iets te kort door de bocht van mij inderdaad: alleen de toegestane syscalls werken, vanwege SecComp: https://kubernetes.io/docs/tutorials/security/seccomp/

[Xander2]

Veel plezier met je shell, maar root heb je niet, syscalls werken niet, geen tooling (want minimaal image) en de interne netwerkpolicy houdt je buiten de rest van het netwerk.

Je kunt tooling uploaden, bestaande code aanpassen, sniffen en verder met CVE's en informatie de rest van je netwerk binnenkomen.

Ik zou je servers maar eens controleren.

[Keypunchie]

Ik heb geen php draaien. Scheelt op een dag als vandaag. Met log4j aan de andere kant, was het wel weer gezellig voor me.

[Xander2]

Dit soort escalaties zijn gewoon heel erg vervelend omdat het een VPS levert aan partijen waarvan je weet dat die kwaad willen en waarschijnlijk de creativiteit en ervaring hebben om dit maximaal uit te buiten.

Het vertrouwen wat jij stelt in installatie is volledig onterecht als dat al gebroken is..

[Keypunchie]

Beetje rare reactie dit? Ik weet toch zeker zelf wel of ik wel of geen PHP uitgerold heb staan?

[Xander2]

Het gaat niet om PHP of persoonlijk, slechts het feit dat elke stack kwetsbaarheden heeft en zal kennen.

[Keypunchie]

Wat is je punt? Eerst zeg je "ik zou je servers controleren", waarop ik aangeef geen PHP te hebben draaien.

Dan zeg je dat mijn vertrouwen daarin onterecht is.... Maar nu is het " elke stack" heeft kwetsbaarheden...

Duh, daarom heb ik.toch juist ook hardening en defense-in-depth?

Dit is niet de eerste en zal zeker ook niet de laatste "zero-day" zijn...

Ga je eigen server nakijken!

[RubenNL]

Niet altijd.

Bijv. ik draai een Nextcloud server en een Jellyfin server.

De enige manier hoe ik weet dat Nextcloud wel PHP draait en Jellyfin niet, is omdat ik het net opgezocht heb.

Ik heb dus alleen Nextcloud offline gehaald.

[Stetsed]

Het probleem komt uit meerdere hoeken, dit zijn namelijk:
1. De applicatie zelf kan all toegang hebben tot sensitieve data, als het een directe database connection heeft voor de app dan kan je hier data uit trekken
2. Containers worden niet door iedereen gedraait, en zeker nu met de recente privilege escalations die worden uitgevonden als je buiten een container zit dan kan je vaak redelijk makelijk naar root komen.
3. Zelfs binnen een container zijn er recent meerdere container escapes uit gekomen, of om precieser te zijn technology die het mogelijk maakt om een effect te hebben buiten je container. Je kan natuurlijk een restrictieve environment hebben met restricted capabilities en inderdaad syscalls, maar er is nog steeds geen garantie.

Dus ja, het moet niet de einde van de wereld zijn. Maar het kan zeker een probleem zijn met hoe veel vulnerabilities er recent uit zijn gekomen.

[Reactie gewijzigd door Stetsed op 21 oktober 2026 16:18]

[OverSoft]

Ja, da's leuk, maar PHP MOET nog steeds bij alle bestanden kunnen die hij serveert.
En die bestanden kunnen ook configuratie instellingen bevatten, keys, wachtwoorden, etc...

Dat je niet buiten je gesandboxde shell komt is leuk, maar PHP moet ook IETS kunnen, want anders heb je er niet zo veel aan. En als PHP het kan, kan de aanvaller dat ook.

[The Zep Man]

Dat je shell kunt krijgen, geloof ik wel. Maar dit is toch precies waarom er ook hardening is uitgevonden?

Veel plezier met je shell, maar root heb je niet, syscalls werken niet, geen tooling (want minimaal image) en de interne netwerkpolicy houdt je buiten de rest van het netwerk.

Veel succes gewenst als je op een enkele laag beveiliging vertrouwt.

Privilege escalation exploits komen regelmatig uit. Men hoeft alleen maar te wachten. Hardening is geen excuus om gebroken beveiligingslagen te negeren.

[Keypunchie]

Uiteraard, patchen. Maar om nou direct ook alle websites die alleen maar content serveren uit te gooien, voelt voor mij wat cru. (Toegegeven, ik heb zelf geen php-sites in beheer, dus ik ben ook niet de diepte ingedoken, maar van wat ik lees moet je voor 1 van de 2 een uploadformulier hebben, wat ook niet iedereen publiekelijk zal hebben, toch?)

[Reactie gewijzigd door Keypunchie op 21 oktober 2026 16:26]

[tszcheetah]

Nee, een uploadformulier is niet nodig om vatbaar te zijn. De mitigatie is om voor sites waarvoor je geen grote upload nodig hebt, PHP ook zo te configureren dat er niet veel geüpload kan worden.

Doordat er nog veel onduidelijk was, maar er wel al exploit-pogingen waren voordat de patch er was, en remote code execution ongeveer het ernstigste mogelijke beveiligingslek is, is het verstandig om de boel offline te halen en te laten totdat er gepatcht is.

[5pë©ïàál_Tèkén]

Speculatie van mijn kant - ik denk dat de impact (/paniek) rond het AH debacle specifiek in Nederland & België (Delhaize in BE) er voor zorgt dat men een issue als dit eindelijk een keer serieus neemt. Op nu.nl lees ik dat in de rest van de EU men niet zo ‘paniekerig’ reageert. Maar ja, wanneer je in je supermarkt lege schappen ziet, dan kan dat voor veel mensen echt een trigger zijn. Veel instellingen dachten misschien dat zij ook in een AH situatie zouden komen.

[SPee]

Daarom denk ik ook dat we AH van het veroorzaken/publiceren van deze lek mogen betichten.
Die wil gewoon wat beter voor de dag komen. En hoe kan dat dan beter dan dat bijna alle websites ook down gaan.

[bzzzt]

Als je PHP scripts toegang hebben tot de database is het toch vrij eenvoudig een exfiltratie uit te voeren. Natuurlijk is er met voldoende middleware en database policies iets op te zetten wat het moeilijk maakt, maar denk niet dat de gemiddelde Wordpress site met een stapel plugins dat heeft...

[ApexAlpha]

HAha je hebt geen tooling nodig... Je hebt PHP.

Ik kan alles extracten met PHP zonder Bash indien nodig.

[Pinkys Brain]

Veel plezier met je login sniffer?

[geeMc]

Hardening? Waarvoor? We draaien toch massaal in containers tegenwoordig en hoeven niet meer na te denken over dit soort dingen? /s

Het laat vooral weer eens een pijnpunt zien waarom oudere SysOps praktijken soms helemaal zo verkeerd niet waren ten opzichte van de snellere DevOps praktijken.

[Polderviking]

Hardening van zo'n webserver is leuk maar je zit wel gewoon onder de gebruikerscontext waar PHP in draait en dingen als data extraheren kan ongetwijfeld wel.
Dat vind ik een veel groter probleem dan wat ze op die webserver zelf verder allemaal nog kunnen doen.

[CH4OS]

Dat je in de shell die je dan krijgt geen root hebt, betekend niet dat je dan niet middels de code die je plaatst met de Remote Code Execution (RCE) bug, die toegang niet uiteindelijk alsnog kunt krijgen. Je gaat in veel van jouw beredeneringen uit van een containerized setup, al dan niet met Kubernetes, maar zo werkt niet iedereen. Ook development omgevingen zijn hierdoor getroffen. Het is niet een kwestie van webservers van productie omgevingen patchen en daarmee is het klaar en opgelost.

[RiDo78]

Ach, er hoeft maar één script met de eigenaar ‘root’ met een suid bit en writable voor de verkeerde groep (of all) en je bent al het haasje. Even het script aanpassen en alles wordt onder de root-user uitgevoerd.

Als de aanvaller er dan ook nog in slaagt om een lokale ssh-verbinding naar diezelfde root-user te maken (bijvoorbeeld doordat de root-user een kopie van zijn private-key heeft staan) dan schudt die ook de confined SELinux context van zich af.

En natuurlijk, bij een juiste hardening audit komt dat vanzelf bovendrijven. Maar gemak dient vaak de mens.

[Alfa1970]

Het gevaar zit hem niet in root verkrijgen. Het gevaar zit hem in het feit dat ze zonder medeweten van de administrator van de site kunnen aanpassen en er dingen op kunnen zetten die er niet op horen te staan. Zoals malware. En als je daar ook een zero-day voor hebt, dan zitten alle bezoekers van een site als Tweakers met een virus dat pas over een week of 2 wordt ontdekt. Hypothetisch gesproken.

[BravoWhiskyAlfa]

Kwetsbaarheden zijn dus ontdekt als onderdeel van OpenAI's Patch the Planet programma:

https://calif.io/php2shell/

https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/

[pdidi]

Dus de volgende vraag is: wie heeft er gelekt? Als er zoveel partijen (Wiz, OpenAI en Calif) bij betrokken zijn geweest is dat misschien nog wel een groter probleem. Hier het filmpje dat vanacht online kwam (bron ArsTechnica)
EDIT: het was dus Calif: Calif, one of the security firms that had reported the issues mistakenly published a video

[Reactie gewijzigd door pdidi op 21 oktober 2026 17:13]

[equit1986]

Chainguard en Calif, twee partijen dus die zich niet in konden houden

[kaas-schaaf]

Als je de kruimels volgt en de pagina's op hackernews leest die hier naar verwijzen kan je er mogelijk achter komen wie (een van de) lekkers is. Er zijn niet veel referenties maar wel enkele (mits ze nog niet verwijderd zijn).

edit: Je hoeft niet meer te zoeken, het staat hierboven al ergens.

[Reactie gewijzigd door kaas-schaaf op 21 oktober 2026 17:10]

[bzzzt]

Vandaar dat disclosure zo lang duurder. Iemand moest de uitleg in stripvorm nog tekenen...

[kaas-schaaf]

Ik kom niet door die pagina's heen. De "officiele" php2shell.com is nog veel erger. Die ziet er eerder uit als een PR praatje dan fatsoenlijke disclosure.

Lees dan de advisories, veel makkelijker te lezen:

• https://github.com/php/ph...ories/GHSA-w8hw-w9fx-j79w
• https://github.com/php/ph...ories/GHSA-6wmf-4rv5-p3rp

[ApexAlpha]

Vroeger was je verbaasd dat een vulnerability een naam had.

Toen was je verbaasd dat ze een eigen website kregen.

Nu heeft deze een comic erbij... Tjonge.

[lenwar]

En over twee jaar een Disney film in IMAX

[Feni]

Blijkbaar hebben een paar partijen zich niet gehouden aan het embargo rondom de disclosure, wat ertoe heeft geleidt dat noodmaatregelen nodig werden. Zij worden in de publicatie van the PHP Foundation niet gespaard:

Leak and disrupted disclosure

The coordinated disclosure of these vulnerabilities worked well until 2 days ahead of the targeted release date.

On Tuesday, October 20th, at around 15:00 UTC, the two CVE IDs began circulating on online forums and social media. They came with a wrong release time and a wrong CVSS score of 10.0 (the actual score is 9.2). No technical details leaked. In response, the PHP project brought its pre-announcement forward and published it at 19:30 UTC. It also moved the release from October 22nd, 14:00 UTC, to October 21st, 14:00 UTC. Distributors were still packaging the fix, so releasing immediately would have left many users without an easy way to update. Moving the release forward by one day was the best compromise between acting quickly, giving people time to prepare, and making sure everyone had a simple update path when the vulnerabilities were disclosed.

As a result of the leak and pre-announcement around 20:00 UTC, Calif, one of the security firms that had reported the issues mistakenly published a video. It showed their proof of concept working against a number of targets and revealed a few additional, though limited, details about the vulnerabilities. Copies of the deleted video started circulating on social media soon after. The video contributed to accelerated development of various PoCs (exploitation proof of concepts), which then increased circulation on October 21st.

Mitigation advice we started providing to a few critical infrastructure providers around Oct 20th 23:00 UTC, may have leaked as well. The PHP security team closely monitored and inspected appearing PoCs after the leak but did not identify any functional exploits at the time of release/public disclosure.

On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix. Like other distributors, Chainguard had received the patch in advance so its users could update the moment the vulnerabilities were disclosed. Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure.

Bron: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

[equit1986]

Chainguard en Calif gaan dus op de blacklist van iedereen in de securitywereld.... Naja hebben ze er zelf naar gemaakt. Die kunnen dus gewoon opdoeken, want gewoonweg niet meer betrouwbaar, in een wereld waar vertrouwen ongeveer een van de belangrijkste zaken zijn die er is..

[ardjuno]

Interessant wel allemaal! Ik zie dat in Nederland toch aardig wat sites offline zijn gehaald, maar dat het buitenland toch redelijk lauw reageerde (volgens nu.nl). Ik ben wel benieuwd wat daar de beweegredenen van zouden zijn. Zou het een domino effect zijn omdat enkele grotere spelers offline gingen, of zijn wij toch sinds de grote Odido en Ahold hack wat meer op onze hoede?

[ries81]

Denk dat Nederland wakker is en de rest nog niet zo. Feit is dat als er een web shell of andere C2 wordt achtergelaten, je nu kan patchen, maar ze toch al binnen zijn en blijven. En dan laten ze over een paar weken je koelkasten overkoken of zoiets.

[-ETz-candyman]

Wij zijn in West-Europe "wakker" voor de USA. We hebben de tijd gehad om de berichtgeving die gisteren laat van PHP de wereld in ging te lezen, analyseren en een besluit te vormen. Verder zitten België en Nederland in de top 10 van IT service providers in de wereld. Mogelijk speelde dat ook mee.

[rgom]

Leuk om nu de comments te volgen hier https://github.com/docker-library/php/pull/1694

[agittunc]

Ik krijg Unicorn! volgens mij is er wat teveel traffic

[rgom]

Ooff.. Zag het sowieso al aan Docker Hub die er ook moeite mee lijkt te hebben. Dat vind ik ook wel interessant aan een incident als dit. Er zijn zo veel dingen waar je (als IT'er) normaliter geen rekening mee houdt die nu ineens heel belangrijk zijn. Zoals zorgen dat je niet afhankelijk bent van bijv Docker Hub voor base images, of dat je niet afhankelijk bent van CI/CD als je een kritische kwetsbaarheid moet patchen

[agittunc]

Je moet altijd een back-up methode hebben. Ook voor automatisering want je weer maar nooit wanneer iets de klote ingaat .

Maar tis wel goed dat t nieuws ervoor zorgt dat er proactief gehandeld wordt voor dit soort kwetsbaarheden.

[Feni]

And it's down..

[lDDQD]

Tweakers was erg snel weer online nadat de patch vrijgegeven was. Hoe gaat dat eigenlijk in de praktijk, moet je zoiets niet eerst testen om te kijken welke afhankelijkheden er zijn etc?

Of moet je bij dit soort kwetsbaarheden gewoon zo snel mogelijk patchen en daarna maar eventueel analyseren of alles nog werkt.

[The Zep Man]

Tweakers was erg snel weer online nadat de patch vrijgegeven was. Hoe gaat dat eigenlijk in de praktijk, moet je zoiets niet eerst testen om te kijken welke afhankelijkheden er zijn etc?

Het gaat om een minor version update. De keuze wordt gemaakt tussen patchen met het beperkte risico dat iets omvalt met de mogelijkheid om een patch terug te draaien om daarna wat langer te wachten, en om een website sowieso langer offline te houden. Het risico op kosten is met dat laatste een stuk hoger.

Als je je landschap goed kent, geen afwijkingen hebt met upstream, je de changelog in de gaten houdt, en wellicht nog een diff doet tussen beide versies om even de verschillen te bekijken, dan kan je met redelijke zekerheid veel risico's vroegtijdig uitsluiten.

[Reactie gewijzigd door The Zep Man op 21 oktober 2026 16:20]

[rgom]

Je kunt een patch als deze vergelijken met een andere patchversie van software. In de regel kun je die gewoon installeren zonder dat het impact heeft. Zoals je iPhone bijvoorbeeld ook 27.1.X versies heeft waar je eigenlijk niks van merkt

[duderuud]

Ik heb op 5 servers de nieuwste PHP gecompileerd, dat duurde ongeveer 10 minuten per server (klaar om 15:49 om precies te zijn).
Gebruik je bijv. Ubuntu met Ondrej repos dan ben je in een minuut of 2 al klaar.

[Reactie gewijzigd door duderuud op 21 oktober 2026 16:32]

[Coffeemonster]

Linkje naar post van @Kees met uitleg. In het kort: Updaten en monitoren. Volgens mij is het een niet zodanig grote update dat de kans groot is dat er dingen stuk gaan, en even testen op één server voordat je het over alle servers uitrolt en weer online zet zou dan voldoende moeten zijn.

[GoodspeeD]

Iemand op een ander forum zei: "Kunnen we stoppen met die spam over één of ander oud en rommelig webtaaltje?"

Dit toont maar weer hoe weinig mensen weten over hoe actueel PHP nog steeds is.

[Webgnome]

ach ja, ik vroeg bij een vergelijkbare post ook aan iemand of ie dat ook vond over java of c++

[Crew One]

En rust. roestig taaltje.

[StefanJanssen]

Ik vergeet nooit hoe de oorspronkelijke ontwikkelaar van PHP zo'n 5 jaar lang heeft volgehouden dat het tijdelijk was tot iemand anders iets beters zou ontwikkelen. Dus ik kan mij zeker inkomen in het "oud en rommelig webtaaltje", maar het is inderdaad nog heel veel gebruikt.

[GoodspeeD]

Sowieso voegt het woord 'oud' weinig toe aan dit soort discussies. Alsof oud hetzelfde is als slecht, en nieuw per definitie beter is. Er is een reden waarom PHP oud is en nog steeds gebruikt wordt. Schijnbaar is het goed.

[-ETz-candyman]

Ergens tussen de 65 en 75% van het moderne web draait op PHP.
Er is veel onwetendheid bij eindgebruikers (en enkele hardnekkige PHP-hatende sysadmins).

[Luctia]

Hey, je kan best een PHP-hatende sysadmin zijn en weten dat PHP nog (pijnlijk?) actueel is.

[WoBBeL]

Hulde voor het snelle updaten aan jullie kant

[Recklezz]

AH heeft wel de toon gezet met snel de stekker eruit halen he? Desalnietemin de juiste en kordate beslissing, goed gedaan!

[olafmol]

Wie zegt dat AH niet "gewoon" ransomware kreeg en netjes heeft betaalt? Ik zou niet direct een pr bericht geloven.