Twee kritieke PHP-lekken kunnen veel verder reiken dan de website van een organisatie. Ook producten van leveranciers en apparaten met een webinterface kunnen kwetsbare PHP-code bevatten.
Minister David van Weel waarschuwt organisaties daarom hun technische afhankelijkheden te controleren. Het NCSC onderzoekt daarnaast eerste internationale signalen van mogelijk misbruik.
Eigen website patchen is niet genoeg
Van Weel schrijft in een
Kamerbrief van 22 oktober dat de fouten niet alleen websites treffen.
PHP kan ook verwerkt zijn in andere softwareproducten en componenten.
Dat maakt de leveranciersketen belangrijk. Een organisatie kan haar eigen servers hebben bijgewerkt, terwijl software van een externe partij nog een kwetsbare PHP-versie gebruikt.
Het kabinet adviseert daarom zicht te krijgen op zulke afhankelijkheden.
Zelfs een webinterface van apparatuur kan geraakt zijn
De nieuwe
beslisboom van het NCSC maakt dat risico concreet.
Als voorbeeld noemt het centrum een apparaat waarvan een webinterface PHP gebruikt om gebruikers te laten inloggen.
De organisatie beheert de PHP-code dan mogelijk niet zelf.
In zo'n situatie moet zij bepalen of die functie vanaf internet bereikbaar is en welke tijdelijke maatregelen nodig zijn. Vervolgens is zij afhankelijk van de leverancier voor een gerepareerde productversie.
Leverancier bepaalt soms wanneer de patch komt
Dat maakt een beschikbare PHP-update nog niet hetzelfde als volledig herstel.
Een softwareleverancier moet de reparatie eerst verwerken in zijn eigen product. Daarna moet worden getest of die wijziging geen nieuwe problemen veroorzaakt.
Het NCSC verwacht daarom dat deze PHP-zaak langere tijd aandacht vraagt.
Voor producten die volledig door een externe partij worden beheerd, adviseert het centrum rechtstreeks contact met die leverancier.
De vraag is dan simpel: is dit product geraakt, welke maatregel geldt nu en wanneer komt een veilige versie?
Aanvallers kunnen op afstand code uitvoeren
Het gaat om twee fouten die remote code execution mogelijk kunnen maken.
Daarbij kan een aanvaller via een kwetsbaar systeem eigen opdrachten uitvoeren zonder eerst geldige inloggegevens te hebben.
Dat kan leiden tot overname van een server, datadiefstal of verstoring van een dienst.
Het
NCSC-beveiligingsadvies behandelt CVE-2026-109618 en CVE-2026-109619 daarom als ernstige fouten.
Nieuwe PHP-versies zijn beschikbaar
Voor regulier ondersteunde PHP-versies zijn beveiligingsupdates uitgebracht.
Het NCSC noemt 8.5.12, 8.4.27, 8.3.36 en 8.2.35 als versies waarin de problemen zijn verholpen.
Organisaties die Linux-distributies of lang ondersteunde pakketten gebruiken, moeten de updates van hun eigen leverancier volgen.
Voor PHP 8.1 en ouder geldt een lastiger verhaal.
Die versies worden niet meer regulier door het PHP-project ondersteund. Vanwege de ernst zijn wel minimale broncodepatches beschikbaar gemaakt voor PHP 7.4, 8.0 en 8.1.
Dat is niet hetzelfde als een normale nieuwe productversie die automatisch bij iedere organisatie binnenkomt.
Oude installaties kunnen meer herstelwerk vragen
Voor oude PHP-systemen kan een volledige upgrade nodig zijn.
Daar zit operationeel risico aan.
Software die jarenlang tegen één PHP-versie is gebouwd, hoeft niet zonder problemen op een nieuwere versie te draaien. Koppelingen met andere applicaties kunnen breken of zich anders gedragen.
Het NCSC waarschuwt daarom dat oudere installaties langer buiten gebruik kunnen blijven.
Eerst weer online gaan en later upgraden is juist bij internetbereikbare systemen een riskante volgorde.
Eerste signalen van mogelijk misbruik worden onderzocht
De status van aanvallen vraagt nauwkeurige formulering.
Van Weel schrijft dat het NCSC eerste internationale signalen van mogelijk misbruik onderzoekt. Het centrum onderhoudt daarover contact met buitenlandse partners.
Dat is nog geen bevestiging dat Nederlandse organisaties succesvol zijn aangevallen.
In zijn publieke update meldde het NCSC eerder geen aanwijzingen te hebben voor succesvol misbruik van de onderzochte kwetsbaarheden.
Die twee mededelingen kunnen tegelijk kloppen: verdachte internationale signalen worden onderzocht zonder dat al is vastgesteld dat een aanval geslaagd is.
Publieke aanvalscode verhoogt wel de druk
Er circuleren al proof-of-concepts.
Dat zijn technische voorbeelden waarmee een kwetsbaarheid kan worden onderzocht en, afhankelijk van de code, mogelijk kan worden misbruikt.
Het NCSC waarschuwt daarom niet te wachten op bevestigde slachtoffers voordat een organisatie handelt.
Een werkende methode kan snel worden aangepast en op veel bereikbare systemen worden geprobeerd.
Van Weel noemt daarnaast AI als factor die de ontwikkeling of toepassing van aanvalsmethoden kan versnellen.
Veel overheidsdiensten kwamen weer online
De kwetsbaarheden leidden eerder deze week tot preventieve sluitingen.
Ook het NCSC zelf en verschillende Nederlandse overheidsdiensten haalden websites tijdelijk offline.
Nadat patches beschikbaar kwamen, konden veel diensten weer worden aangezet.
Maar bereikbaarheid zegt alleen dat een bepaalde dienst opnieuw gebruikt kan worden.
Het bewijst niet dat ieder ander product binnen dezelfde organisatie of leveranciersketen automatisch is bijgewerkt.
Voor crypto ligt hetzelfde onderscheid
Dat punt geldt ook voor cryptobedrijven.
Een
blockchain kan gewoon blokken blijven verwerken terwijl een website of klantportaal tijdelijk offline moet.
Een
crypto-exchange kan daarnaast software van externe leveranciers gebruiken voor webdiensten, ondersteuning of andere functies.
Hetzelfde geldt voor bedrijven rond
wallets.
Een fout in zo'n weblaag betekent niet automatisch dat privésleutels of de blockchain zelf zijn geraakt. Maar de afhankelijkheid moet wel afzonderlijk worden onderzocht.
PHP blijft nog langer een aandachtspunt
Het NCSC verwacht niet dat deze zaak na één patchdag voorbij is.
PHP zit breed verspreid in producten. Leveranciers moeten reparaties nog verwerken en oude systemen kunnen meer werk vragen voordat zij veilig terugkomen.
Daarom is alleen vragen “hebben wij PHP?” te beperkt.
De nuttigere vraag is: in welke eigen én ingekochte systemen draait het, wie beheert die software en wie zorgt dat de reparatie daadwerkelijk wordt geleverd?
De patches zijn er.
Nu moet iedere organisatie nog zeker weten waar ze allemaal terecht moeten komen.