NCSC krijgt eerste signalen dat PHP-lekken succesvol zijn misbruikt

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.

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 proofs-of-concept 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 ging woensdagmiddag uit voorzorg offline.

Reacties (87)

[max3D]

Hoe checkt de NOS de php versies van websites? Ik dacht dat we die niet exposeren?

[ThomasG]

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.

[kroam]

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. De uitleg is ook niet volledig want je geeft niet alleen aan dat je PHP gebruikt op je server, maar ook welke versie.

; 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

[Reactie gewijzigd door kroam op 23 oktober 2026 11:45]

[Drumar]

Dit is een discussie die al heel lang rondgaat: het exposen maakt je niet vulnerable, het niet patchen wel. Men gaat er daarbij vanuit dat security through obscurity geen security is. Daar hebben ze op zich gelijk in, alhoewel het voor een aanvaller natuurlijk een stuk makkelijker is te zien welke versie er gedraaid wordt, zodat die weet welke exploits er zouden kunnen werken.

Daar zit precies de crux: als je de versie niet vermeldt, ben je niet opeens wel veilig.

Apache httpd hanteert overigens hetzelfde principe. Je kan de Server header niet uitzetten of een andere obscure waarde geven of leeg maken (behalve met mod_security overigens), of de code aanpassen voordat je die zelf compileert.

[E!Ma0RB7]

Die "security through obscurity"-discussie vind ik zo vermoeiend, omdat beide kampen gelijk hebben, ze dezelfde woorden gebruiken, maar iets anders bedoelen.

Het verschil zit hem in de scope van de risicobeoordeling.

In casu, beoordeelt PHP de tool zelf. Deze is, binair gesteld, veilig of kwetsbaar. Een veilige versie vormt dus geen probleem en dus kan je het versienummer gewoon delen. Het nummertje van een versie maakt de versie niet kwetsbaar; de code in die versie potentieel wél. En dat klopt als een bus!

In bredere scope verlaagt obscurity wel degelijk de waarschijnlijkheid van een aanval wanneer je een risicototaalbeeld van de hele context bekijkt. Systeem veiligheid wordt niet alleen bepaald door de PHP versie. Misschien zijn er aanvals vectoren alleen mogelijk met bepaalde ( op zichzelf veilige) PHP versies. Daarnaast is het niet te ontkennen dat bij (on)bekende kwetsbaarheden in een bepaalde versie, het waarschijnlijker is dat jouw systeem wordt aangevallen, wanneer je systeem gemakkelijk te herkennen is, doordat je zelf 'adverteert' met dat je een bepaalde versie runt. Klopt ook als een bus!

In conclusie: het is is goed en mag (en moet) bestaan dat de ontwikkelaar sec kijkt naar de veiligheid van een tool (en daarbij obscurity niet als beveiliging gaat beschouwen) en de gebruikers van die tool obscurity wél meenemen.

[Reactie gewijzigd door E!Ma0RB7 op 23 oktober 2026 07:51]

[Groax]

Dat ligt echt aan de developer.. Zoals iedere programmeer taal. PHP is zeker niet minder veilig omdat het PHP is.

[latka]

Het is een cultuur ding: de meeste PHP code die ik heb gezien is organisch gegroeid in een cultuur van 'he, dat is handig'. Het is niet inherent aan de technologie, wel aan het soort ontwikkelaars wat de technologie aantrekt. Momenteel zie je dit heel sterk in het Javascript framework landschap.

[GS3315]

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.

[Barsonax]

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.

[ocn]

Dat noemen ze security through obscurity. Niet echt security dus.

[Barsonax]

Goede security werkt in lagen en ervoor zorgen dat hackers niet precies weten welke versies je gebruikt is daar een van. Niet voor niets dat dat gelijkt geflagged wordt bij een security review.

Anders is het makkelijk een lookup doen op open CVE's en daar een hack omheen bouwen wat met AI zo gepiept is.

[satya]

Hangt er van af hoe je het bekijkt.

De hackers scene scant continu het volledige internet af om te bepalen wat waar draaid en dat bij te houden, met daaroverheen een register om te zien wie van hun potentiële interesses kwetsbaar is om onmiddellijk aan te kunnen vallen.

[ocn]

Klopt hoor. De grap is wel dat als je als organisatie zelf je landschap niet goed in beeld hebt, je zelf ook niet meer makkelijk kan scannen waar je kwetsbaar voor bent. Maar goed, daar zou je APM met CMDB en SBOM voor moeten inrichten.

[Xilonz]

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...

[DJMaze]

Ubuntu doet hetzelfde met versies vs patchen...

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

[niekdejong]

Hm nee, maar Canonical doet backports en hoogt wel degelijk de versies op.

[Noscript]

Maar echt, heb dit vandaag 100x moeten uitleggen aan klanten en begrijp dat klanten het dan nog niet snappen…

[HostMan]

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.

[bazzi]

Ja ze waren laaaaaat ook met releasen. Daar schrok ik van, want ik verwachtte dat ze wel in de innercircle zouden zitten met php. Zeker als je zag hoe snel cpanel de versies had opgehoogd en hoe traag cloudlinux was…
Ze maken een mooi product, maar dit was wel een moment waarvan ik dacht, shit, dit is wel echt een faal!

[LEiPiE]

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.

[Woefdramcx]

Exposeren? Dat doe je op een expositie 😄

[nicenemo]

Sommige mensen verstaan Vlaams prima. Exposeren versus blootstellen. Vlaams is hier wat efficiënter.

Correctie: bloot stellen -> blootstellen 😃👍

[Reactie gewijzigd door nicenemo op 23 oktober 2026 16:22]

[Cybje]

Er is trouwens ook een belangrijk verschil tussen "bloot stellen" en "blootstellen"

(maar uiteraard snapt iedereen gewoon wat men bedoelt, net als met het woord "exposeren")

[Woefdramcx]

Vlaams? Of gewoon een foute vertaling van het Engelse "expose"..?

[Dennahz]

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.

[oef!]

De komende tijd gaan we er gegarandeerd achter komen dat en hele hoop bedrijven en personen niet handig bezig zijn

[m_aar_ten]

Ik denk dat je zwaar overschat hoe strak mensen op hun patches zitten 😅

[_JGC_]

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.

[servies]

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?

[nicenemo]

Tja die is er mogelijk nog niet voor b.v. OpnSense routers. Natuurlijk heb ik management interface niet aan het internet hangen maar toch.

Veel embedded devices die al jaren geen updates meer krijgen of waarvan de gebruiker niet eens weet dat de php web interface bestaat.

Ik ben benieuwd hoe dit gaat met de routers die providers hebben uitgerold.

[xmicks]

Ik weet niet of je dit bedoelde maar, Opnsense heeft de php patch woensdag al direct in een update voorzien.

[nicenemo]

ik heb vanmiddag nog naar updates gekeken op mijn router, nog niets

[xmicks]

Hier de announcement van de update.

OPNsense: PHP2Shell (CVE-2026-109618, CVE-2026-109619) fix for 26.4.2p4, 26.1.11, 26.7.7

Tweakers: Software-update: OPNsense 26.7.7 hotfix

[nicenemo]

thanks, ik zit op de juiste versie. Morgen alleen nog de travel router nalopen.

[Barsonax]

En dat zal helaas het merendeel zijn

[rekeewt]

Amazon zag een week geleden al aanvallen…

[Bedge85]

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.

[dasiro]

poging kan ook impliceren dat ze misschien niet willen aangeven of ze succesvol was

[Memori]

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]

[HakanX]

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?

[mace]

Aanvallen, maar geen succesvol misbruik.

[rekeewt]

Een week voor het publiek worden van de vulnerability… 1+1=2, weet zeker dat er succes achter zat.

[Jan121]

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

[lenwar]

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.

[Lordfox73]

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.

[lenwar]

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.

[MrMarcie]

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.

[paradoXical]

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

[lenwar]

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.

[mocean]

Ik denk eerder legacy meuk bij bedrijven dan hobbyisten hoor...

[phray]

Er zijn genoeg leveranciers die nog oudere versies van PHP leveren met backports van de fixes. (Vaak wel tegen prijs).

[voda]

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.

[halfgaar]

Ubuntu 24.04 komt met PHP 8.3. Als jij iets van sory.org hebt, is het maatwerk?

[voda]

Zeker, ook voor Ubuntu 22.

Check:

https://launchpad.net/~ondrej/+archive/ubuntu/php/+index?batch=75&memo=225&start=225

[ries81]

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.

[CapnCrinkle]

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.

[jared9]

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.

[Roel1966]

Hmm, blijkbaar is DigiID nog bezig want opeens start bij mij de DigiID app niet meer op en sluit zichzelf direct weer. Wel werkt DigiID gewoon via de Windows app vreemdgenoeg, dus weet niet of dit aan mijn smartphone ( Oneplus Nord 5, volledig geupdate ) ligt of dat de app zelf nog offline is.

[Jedotw]

De website van DigiD is gebouwd met Drupal, dus op basis van PHP. Die heeft echter niets te maken met de voorziening DigiD of de app van DigiD, die beide met andere talen gebouwd zijn. Waarschijnlijk is er iets anders aan de hand.

Er wordt wel vaker geroepen "DigiD doet het niet" terwijl de website (!) van de organisatie die inloggen met DigiD biedt niet (correct) werkt. De organisatie is verantwoordelijk voor de website, pas na het klikken op de knop "Inloggen met DigiD" wordt de voorziening aangeroepen en wordt het standaard inlogscherm van DigiD getoond.

[Urk]

Dat vind ik eigenlijk al bizar dat de DigiD webite is gebouwd met Drupal... Waarom geen maatwerk?

[uiltje]

Omdat het schrijven van een complete web-server enorm veel werk is, en dat dat ook nog eens bijgehouden moet worden. Het gaat erom dat de authenticatie-service in zelf goed werkt. Dat is wat anders dan dat de frontend 100% dicht staat - voor zover dat al bestaat en aangenomen dat maatwerk per definitie veiliger is (waar ik mijn ernstige twijfels bij heb, en ik heb ooit een maatwerk security lib gebouwd omdat ik de software van toendertijd niet vertrouwde - achteraf bleken die inderdaad een enorm probleem te hebben).

[demianmonteverd]

php -S localhost:8000 testserver.php

ruby -rwebrick -e'WEBrick::HTTPServer.new(Port: 8000, DocumentRoot: ".").start'

In java hebben ze de JEP 408 standaard.

Of gebruik een andere taal. Of doe iets als caddy hergebruiken als je meer features nodig hebt en geen zin hebt om een 'webserver' te maken. Je kunt zelfs programmeren in je proxy desnoods (nginx, varnish (nieuwe naam even vergeten), haproxy, etc.).

Niet dat je zoiets wilt doen voor digid, maar we zitten hier op tweakers en voor thuis is het wel lekker als je gewoon met iets simpels kan beginnen.

[uiltje]

Ja, OK, maar da's hetzelfde als een bestaande web-server gebruiken als het gaat om beveiligingsissues. In plaats van in de app zitten die nu in de lib.

[markoverklift]

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.

[MiesvanderLippe]

Signalen zullen wel zijn;

Een hostingprovider klaagt, een honeypot is gepakt, een site met network monitoring had inkomend verkeer en daarna een webshell.

[DefaultError]

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’.

[_Eend_]

Ik was 1 klein, persoonlijk webservertje op een VPS vergeten. Ik zag op de statistics pagina van de hoster dat er gisteren rond 8-9 uur (het grafiekje is niet heel duidelijk) dat er ineens een piek aan inkomend verkeer was, en daarna niet veel maar wel regelmatig uitgaand verkeer. Dat was dus al ruim voordat de geruchtenstroom op gang kwam, en op deze machine worden (security) updates automatisch geinstalleerd. (wat ook een van de redenen was dat ik 'm was vergeten).

Nadat ik de VPS had uitgezet en afgesloten van de buitenwereld heb ik een image van het ding getrokken. Van het weekend maar even kijken wat er is gebeurd.