Home   2026-10-22 19:56:51

←

NCSC krijgt eerste signalen dat PHP-lekken succesvol zijn misbruikt

Original article

Het Nederlandse Nationaal Cyber Security Centrum ziet 'eerste signalen' dat de PHP2Shell-kwetsbaarheden succesvol zijn misbruikt. De organisatie had eerder nog geen misbruik geconstateerd. Het NCSC doet momenteel onderzoek.

Dit nieuws in het kort

  • Het NCSC heeft signalen ontvangen van succesvol PHP2Shell-misbruik en doet daar onderzoek naar.
  • De organisatie waarschuwt dat de situatie snel kan verslechteren.
  • Het installeren van de updates is de enige echte oplossing; mitigaties verhelpen het probleem niet volledig.

"Op dit moment onderzoekt het NCSC eerste signalen van succesvol misbruik", schrijft de securityorganisatie in een update op zijn PHP2Shell-pagina. Ook tegenover de NOS zegt het NCSC dat het signalen van succesvol misbruik heeft ontvangen. Wat die signalen precies inhouden, is niet bekend.

"Pogingen om het lek te misbruiken gaan al sinds gisteren rond. We hebben contact met allerlei organisaties in binnen- en buitenland, en via die weg krijgen we signalen binnen dat er misbruik plaatsvindt", zegt een woordvoerder tegen de NOS.

PHP-gaten. Bron: Tweakers
De gaten in de scriptingtaal PHP worden mogelijk misbruikt, blijkt uit 'signalen' van het NCSC. Bron: Tweakers

Alleen updaten helpt

Eerder zei het NCSC dat het nog geen succesvol misbruik had geconstateerd. Er gingen al wel proof-of-concepts rond: stukken code die aantonen dat de PHP-lekken uitgebuit kunnen worden.

Het NCSC waarschuwt dat de situatie snel kan verslechteren. Website-eigenaren wordt daarom met klem aangeraden om de updates zo snel mogelijk te installeren. Systemen die nog niet geüpdatet kunnen worden, kunnen beter offline blijven totdat de patches zijn geïnstalleerd.

Er zijn wel mitigaties voor de kwetsbaarheden bekend, maar die zijn niet waterdicht. Alleen de updates, die gistermiddag verschenen, kunnen de kwetsbaarheden daadwerkelijk oplossen.

Veel websites lijken inmiddels beschermd

Uit onderzoek van de NOS blijkt dat veel websites inmiddels beschermd zijn. In Nederland gaat het zeker om 113.000 websites die de updates hebben geïnstalleerd. Het nieuwsmedium stelt daarbij dat zo'n 145.000 Nederlandse websites mogelijk nog steeds kwetsbaar zijn, al valt dat niet met zekerheid te zeggen.

De PHP-kwetsbaarheden kwamen woensdagochtend aan het licht, eerder dan eigenlijk de bedoeling was. De kwetsbaarheden kunnen relatief simpel uitgebuit worden en hebben grote gevolgen. Ze maken het mogelijk om websites over te nemen en daar bijvoorbeeld data te stelen of malware te verspreiden.

Veel websites en diensten gingen woensdag daarom uit voorzorg offline, waaronder verschillende overheidsdiensten, DigiD, de Schiphol-app en meer. Ook Tweakers ging woensdag preventief offline.

Tweakers neer
Tweakers ging woensdagmiddag uit voorzorg offline.

Door Daan van Monsjou

Nieuwsredacteur

Feedback • 22-10-2026 19:04 59

22-10-2026 • 19:04

59

Lees meer

Reacties (59)

Hoe checkt de NOS de php versies van websites? Ik dacht dat we die niet exposeren?
PHP voegt standaard de header X-Powered-By: PHP/versie toe. Dan kun je precies zien welke PHP-versie een website gebruikt. Dat is uit te schakelen via de php.ini, of te verwijderen door een reverse-proxy. Maar standaard staat het aan, dus laten heel veel websites het zien.
Of ze gebruiken één van de tools die inmiddels op internet te vinden zijn, zoals die van pentest-tools.com waarmee iedereen vrij gemakkelijk kan checken of een server vulnerable is voor CVE-2026-109618 and CVE-2026-109619. Zo circuleren er inmiddels al wel meer sites.
Opzich apart dat dat standaard aanstaat want dat is natuurlijk makkelijk scannen en weten welke vulnerabilities er zijn. Je kan dat beter uitzetten. Dat helpt weer een beetje door het hackers iets moeilijker te maken.
Ik zet het altijd uit: hoe minder informatie je onnodig prijsgeeft, hoe beter. Wel bijzonder dat PHP zelf aangeeft dat het op zichzelf geen beveiligingsrisico vormt:

; Decides whether PHP may expose the fact that it is installed on the server
; (e.g. by adding its signature to the Web server header). It is no security
; threat in any way, but it makes it possible to determine whether you use PHP
; on your server or not.
; https://php.net/expose-php

expose_php = Off
Ik zou PHP en security zowiezo niet in 1 zin willen gebruiken. Dit soort statements geven ook aan dat men security in depth niet snapt.
Dat, plus dat o.a cloudlinux geen nieuwe versie heeft uitgebracht en dus een gepatchte versie en niet gepatchte variant met dezelfde versie bestaat. Ik heb daar mijn mening over...
Ubuntu doet hetzelfde met versies vs patchen... :'(

[Reactie gewijzigd door DJMaze op 22 oktober 2026 21:47]

Hm nee, maar Canonical doet backports en hoogt wel degelijk de versies op.
Maar echt, heb dit vandaag 100x moeten uitleggen aan klanten en begrijp dat klanten het dan nog niet snappen…
Je licht je mening niet toe, maar ik weet zeker dat ik het er mee eens bent.

Ik had altijd een vrij hoge pet op van CloudLinux en heb vanaf toen CloudLinux nog een kind was al goed contact met ze, maar in hun aanpak gister en vandaag zijn er veel fouten en verkeerde keuzes gemaakt.

Ook wij hebben héél vaak aan panikerende klanten moeten uitleggen dat ze wel op een veilige versie zaten, ondanks dat het versienummer nog hetzelfde is.

Waarom CloudLinux als eerste begon met de backports voor oudere EOL versies en niet hun prioriteit hadden op de moderne versie is onbegrijpelijk.
Dat vroeg ik mij ook af, misschien een extrapolatie van een paar die het wel laten zien.

Kwam er gisteren wel achter dat een van mijn vms nog wel expose aan had staan, de rest niet.
Exposeren? Dat doe je op een expositie 😄
Amazon zag een week geleden al aanvallen…
Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026
In deze is het belangrijk om onderscheid te maken tussen een poging en een daadwerkelijke hack. Tot nog toe was er enkel bekend dat er pogingen gedaan worden om het lek uit te buiten. Het NCSC geeft nu aan signalen binnen te krijgen van succesvolle misbruik van het lek.
poging kan ook impliceren dat ze misschien niet willen aangeven of ze succesvol was
En de onderscheid tussen het identificeren van een poging op 17 oktober, en iets "een week geleden" zien. Ze zagen een week geleden niets. Ze gingen gisteren in de logs en zagen toen dat er op 17 oktober een poging was.

[Reactie gewijzigd door Memori op 22 oktober 2026 21:13]

Het eerste wat je doet als je binnen bent is je sporen wissen. Dus als ze eerder binnen zijn geweest, hoeft daar geen sporen van zichtbaar te zijn. Normaal gesproken zorg je er ook voor dat je de deur achter je dicht doet, maar in dit geval was dat niet mogelijk.
Dat betekend dat er na een succesvolle hack nog nieuwe pogingen door anderen zichtbaar kunnen zijn. Nu is de deur wel dicht, maar is de inbreker binnen of buiten?
Aanvallen, maar geen succesvol misbruik.
Een week voor het publiek worden van de vulnerability… 1+1=2, weet zeker dat er succes achter zat.
Tja, inmiddels staat de patch al een dag online. Zelfs voor oudere versies van PHP. Als je deze nu nog niet hebt uitgerold dan ben je natuurlijk niet echt handig bezig.
De komende tijd gaan we er gegarandeerd achter komen dat en hele hoop bedrijven en personen niet handig bezig zijn :/
Ik denk dat je zwaar overschat hoe strak mensen op hun patches zitten 😅
Ik had 1 server die nog niet in de monitoring zat en sowieso nog niet afgeconfigureerd was, gisteren dus niet meegenomen in de patchronde. Die hebben ze vandaag proberen aan te vallen zag ik in de accesslogs. Maar bij gebrek aan PHP bestanden in /var/www/html en juist geconfigureerde handler in de config zijn die hacks nooit bij PHP aangekomen.
Ik had 1 server die nog niet in de monitoring zat en sowieso nog niet afgeconfigureerd was, gisteren dus niet meegenomen in de patchronde. Die hebben ze vandaag proberen aan te vallen zag ik in de accesslogs. Maar bij gebrek aan PHP bestanden in /var/www/html en juist geconfigureerde handler in de config zijn die hacks nooit bij PHP aangekomen.
Als deze nog niet afgeconfigureerd was, waarom was deze dan bereikbaar vanaf het internet?
En dat zal helaas het merendeel zijn
Inmiddels zijn ook oudere PHP versies gepatched, bijvoorbeeld php5.6 op debian/ubuntu 24.04 LTS

5.6.40-105+ubuntu24.04.1+deb.sury.org+1
En dat is geen goede zaak. Die hele oude versies van PHP moeten zo lek als een mandje zijn. Deze ene patch gaat er waarschijnlijk voor zorgen dat die oude, lekke spullen nog langer gebruikt worden.

Als ze die versies continu bijhouden is het overigens wel prima natuurlijk.
Probleem is natuurlijk dat je je als niet-al-te-technische websitehouder waarschijnlijk nu wel beseft dat je naar een nieuwere versie van PHP moet, maar dat dit niet zo maar kan. Want als je niet bij je site kunt, kun je ook niet updaten voordat je de PHP versie omhoog brengt.
Dus als ze de oude PHP versies nu direct blokkeren dan komen er een heleboel websites niet meer terug, en heb je een heleboel boze klanten.

Wat je natuurlijk wel kunt doen - en m.i. ook wel had mogen doen, is zo'n 1½ jaar na end-of-life van een versie aankondigen dat de klant moet updaten omdat de versie na een half jaar verwijderd wordt.

Dan kunnen klanten ook niet boos worden - ook al hadden die zelf dat natuurlijk gewoon moeten bijhouden. Maar ja, dat is soms best lastig als je het niet zo goed snapt.
Maar we hebben het hier over PHP 5.6 die sinds januari 2019 EOL is.

https://www.php.net/supported-versions.php
Het is natuurlijk heel onpraktisch dat er ieder jaar een nieuwe versie van PHP uitkomt. Dus anderhalf jaar is hier niet praktisch. (Je kunt natuurlijk ook versies overslaan).
Maar als we naar praktijksituaties kijken: Een niet al te technische websitehouder zal zeer waarschijnlijk gewoon een off-the-shelf product pakken als Wordpress. Daar wordt de PHP-versie verschoven naar het probleem van Wordpress, en niet van die websitehouder.
Klanten zijn opeens wakker geworden. Nu kan je ze ook duidelijk maken dat bijvoorbeeld van 8.1 naar 8.2 geen zin heeft vanwege eol soon. Dus elk nadeel heb zijn voordeel. ;) Ze zijn geschrokken, prima dus.
Natuurlijk is dit wel een goede zaak, het is niet altijd mogelijk om direct te patchen. Genoeg hobbyisten die hiermee wat tijd winnen om hun zaakjes wel op orde te krijgen
PHP 5.6 is heeft een EOL uit januari 2019.

Het gaat hier niet om patchen van bestaande software, maar upgraden naar een hogere versie. De PHP foundation heeft ook netjes gedocumenteerd waar je rekening mee moet houden voor je migratie naar een hogere versie: https://www.php.net/eol.php
Genoeg hobbyisten die hiermee wat tijd winnen
Nou ja. Dat is helemaal niet gezegd. Als PHP 5.6 zo lek is als een mandje en er is één pleistertje geplakt op één van de vele lekken die toevallig wat groter in de media is gekomen, dan schiet het natuurlijk nog steeds niks op.
Ik denk eerder legacy meuk bij bedrijven dan hobbyisten hoor...
Er zijn genoeg leveranciers die nog oudere versies van PHP leveren met backports van de fixes. (Vaak wel tegen prijs).
De urgentie is nu gelukkig wel duidelijk bij veel mensen. Deze packages geven wel net even wat extra tijd om de boel goed te updaten.
Assume compromise. Als je een PHP server hebt draaien moet je ervan gaan dat ze een of meer C2s hebben achtergelaten. En daar actief naar op zoek gaan.
Yep. Wij hebben vandaag alle systemen nagelopen.

Hierin hebben we in een oud (gelukkig nagenoeg leeg) systeem een hack gevonden die hier verder niets mee te maken had, maar toch interessant. Was een niet heel veel minder zwaar probleem, maar wel limited tot dat nagenoeg lege systeem, gelukkig. Meteen maar even opgeschoond. Wat het precies buitgemaakt heeft (als iets) weten we eigenlijk niet, maar zoals ik al aangaf was er niet veel te halen. We weten wel dat het is binnengekomen via een plugin van het framework. Was maar een testproject en zijn nooit verder doorgegaan met die plugin.

Verder leek bij ons alles helemaal oké. Er zijn wel veel bots langsgeweest gisteren maar of dat de PHP2Shell was is niet helemaal duidelijk. In ieder geval niet de soorten logs die je erbij zou verwachten volgens de informatie die we tot nu toe hebben kunnen vinden gelukkig.

Maar ik begreep ook dat het nog niet helemaal 100% bekend is welke factoren nodig zijn voor de leak om te werken. Het allergrootste risico leek te bestaan als je mod_php gebruikte van apache. Die hebben wij gelukkig niet. Misschien door het oog van de naald gekropen.
Hoe doe je dit dan? Zijn er tools voor? Ik kan wel aan de slag gaan met de bestaande commando's, maar dat geeft zoveel data terug dat er niets van te maken is.
Heel netjes om eerst alles meteen uit te schakelen en te updaten en daarna pas aan klanttevredenheid en verklaringen te werken. Weer goed het voorbeeld gegeven.
Signalen zullen wel zijn;

Een hostingprovider klaagt, een honeypot is gepakt, een site met network monitoring had inkomend verkeer en daarna een webshell.
Een aantal mail&website providers waren een tijd terug al het haasje. Nu is het aan de grote klok gehangen.

Kwestie van doorschakelen en alle oudere systemen loskoppelen en als het lukt van updates voorzien. ‘Thats the way it works’.
Sorry hoor maar als je na al deze trammelant alsnog het nut niet zag om actie te ondernemen dan zou ik de boel offline halen en niet meer terug online zetten.

[Reactie gewijzigd door allabouteve op 22 oktober 2026 19:22]

Even teruglezen bij de eerdere nieuwsberichten. Daar kwamen er een aantal voorbij die de boel offline halen wel erg dramatisch vonden. :+
bleek dus al week van te voren werd misbruik die cve
Tenzij je een honeypot draait.
Tweakers was gisteren opeens offline en stond er 1 regel dat Tweakers offline was. Later kwam het uitgebreide We zijn even offline verklaring, waarvoor dank.
Was het allemaal echt nodig? Dat vraag ik me, als halve leek, af.
Dat is een makkelijke vraag om achteraf te stellen.

Kort ongemak dat misschien niet nodig is is achteraf uit te leggen, onnodig risico lopen met mogelijk desastreuze gevolgen niet.

Alle providers/websites die kozen voor ongemak en offline gingen hebben de juiste keuzes gemaakt.

Om te kunnen reageren moet je ingelogd zijn