Eén ongepatcht PHP-lek en uw supply chain ligt stil

Door Toon Vanagt · 22 oktober 2026

Ook logistiek.be was even kwetsbaar, maar werd gisteren bijgewerkt

Logistiek.be draait namelijk op het WordPress CMS (Content Management System), en WordPress draait op PHP. Toen dinsdagochtend duidelijk werd dat er een ernstig lek in PHP zat, waren wij dus net zo kwetsbaar als een groot deel van het internet. Woensdag, zodra de herstelversie uitkwam, hebben we onze server bijgewerkt.

We schrijven dit niet om onszelf op de borst te kloppen. We schrijven het omdat dezelfde vraag deze week op het bureau van elk logistiek bedrijf hoort te liggen: is onze website, ons klantenportaal, WMS, TMS of ons oude track-and-trace-systeem al bijgewerkt? Dit artikel legt uit wat er gebeurd is, wie nog risico loopt en welke vraag u aan uw IT-mensen of leverancier moet stellen. U hoeft er zelf niets technisch voor te kennen.

Wat is er gebeurd?

Op dinsdag 20 oktober lekten de details uit van twee ernstige fouten in PHP, de programmeertaal waarin een groot deel (69%) van het web geschreven is. Ze kregen samen de bijnaam PHP2Shell (officieel CVE-2026-109618 en CVE-2026-109619). Beide zijn door het PHP-team zelf als kritiek ingeschaald, met een score van 9,2 op 10. In mensentaal: iemand die niets met uw bedrijf te maken heeft, kan vanop het internet uw server opdrachten laten uitvoeren, zonder wachtwoord en zonder dat u het merkt. Dat heet remote code execution.

Wat deze week anders was dan anders: het lek werd bekend vóór de pleister bestond. Normaal werkt het omgekeerd. Onderzoekers melden een probleem in stilte, de ontwikkelaars maken een herstelversie klaar, en pas als die beschikbaar is wordt uitgelegd wat er mis was. Hier lekte de informatie een dag te vroeg. De herstelversies kwamen pas op woensdag 21 oktober om 16 uur Belgische tijd. Cloudflare zag de eerste aanvalspogingen al om 9u43 die ochtend, dus ruim zes uur voor er iets te installeren viel.

Daardoor hebben IT-afdelingen wereldwijd een hectische week achter de rug: eerst noodmaatregelen treffen, dan zodra de update beschikbaar was alles wat aan het internet hangt bijwerken en herstarten.

Waarom dit bijna iedereen raakt

PHP is geen exotisch stukje software. Bijna 70 % van alle websites waarvan de technologie bekend is, draait erop (W3Techs). Het zit onder bijna elke bedrijfswebsite, en onder heel wat portalen en webshops die u dagelijks gebruikt zonder erbij stil te staan.

Concreet gaat het om alles wat op deze platformen gebouwd is:

• WordPress, het systeem achter zowat vier op de tien websites, inclusief de onze
• Joomla en Drupal, de twee andere grote systemen voor bedrijfswebsites
• Magento/Adobe Commerce, PrestaShop en WooCommerce, de populairste webshopsystemen; onderzoekers toonden aan dat de aanval tegen Magento effectief werkt (Sansec)
• Symfony en Laravel, de bouwdozen waarmee IT-bedrijven maatwerk maken, zoals klantenportalen, boekingsmodules, track-and-trace, en koppelingen met douane- of TMS-software
• Beheersoftware voor webservers zoals Plesk, die PHP zelf meelevert.

De fout zit niet in die producten zelf, maar in de laag eronder. Het is een beetje zoals een fabricagefout in een type remschijf: het maakt niet uit welk merk vrachtwagen u rijdt, als die onveilige remschijf erin zit, moet hij zo snel mogelijk vervangen worden om schade te vermijden. Ook oudere, niet langer ondersteunde PHP-versies vragen om extra aandacht. De precieze bescherming hangt bij zulke installaties af van de leverancier en eventuele teruggeplaatste beveiligingspatches (NCSC-NL).

Wie heeft het al opgelost, en wie zit nog vast?

Bedrijven met een eigen IT-team of een gespecialiseerde dienstverlener konden sinds woensdagnamiddag patchen: de fout is gedicht door de nieuwe versie te installeren. Dat is de enige volledige oplossing. PHP zelf is daar duidelijk over: er bestaan geen volwaardige tussenoplossingen, bijwerken is de enige veilige keuze (PHP 8.4.27).

De veilige versies zijn:

Bronnen: Qualys, Plesk.

Daar zit het probleem voor een deel van de sector. Wie nog op een oud besturingssysteem met een oude PHP draait, kan vaak niet gewoon op bijwerken klikken. Volgens W3Techs draait nog altijd zo’n 6 à 7 % van alle websites op PHP 5, een reeks die al jaren niet meer onderhouden wordt.

Voor die bedrijven is er wel een tussenoplossing: een beschermlaag tussen het internet en de server, zoals Cloudflare of een andere web application firewall. Die herkent het patroon van de aanval en blokkeert het voor het de server bereikt. Het is geen genezing, wel een pantser rond een zieke patiënt, en het koopt tijd om de echte oplossing te plannen: migreren naar een onderhouden versie.

Het grootste gevaar: de bedrijven die het niet weten

De kleinere transporteurs, expediteurs en magazijnen zonder eigen IT-dienst vormen nu het grootste risico. Hun website of portaal werd ooit door een webbureau gebouwd en wordt sindsdien ad hoc onderhouden: er wordt pas iets aangepast als er een nieuwe functie nodig is. Niemand kijkt wekelijks of de onderliggende software nog veilig is. De computers die de etiketten afdrukken, of die de gewichten van de vrachtwagen weegschaal uitlezen,  werden vaaak al jaren niet meer bijgewerkt. Bij bedrijven waar updates uitblijven, kan het risico onopgemerkt blijven bestaan.

En dat is om twee redenen een probleem:

1. Uw eigen gegevens. Uw gehackte server geeft toegang tot alles wat erop staat: klantenlijsten, tarieven, vrachtbrieven, douanedocumenten, facturen, wachtwoorden en koppelingen naar andere systemen. Onderzoekers hebben aangetoond dat via dit lek ook het werkgeheugen van de server uitgelezen kan worden, waar wachtwoorden en API-sleutels in rondzweven (Qualys).
2. De gegevens van uw bezoekers. Eens uw webserver is overgenomen, kan de aanvaller er een stukje schadelijke code op plaatsen, een zogenaamde payload. Bezoekers kunnen daardoor bijvoorbeeld worden doorgestuurd naar schadelijke pagina’s of misleidende inhoud te zien krijgen. Uw website wordt dan een verspreidingspunt. Dat is niet alleen een reputatieprobleem, het is ook een aansprakelijkheidsprobleem.

Daarom één nuchtere aanbeveling: laat iedereen die een website, portaal of webshop voor u beheert deze week schriftelijk bevestigen dat de onderliggende PHP-update is uitgevoerd, en op welke versie u nu draait en hoe lang die nog onderhouden zal worden. Een mail van drie regels volstaat. Als het antwoord uitblijft of vaag is, weet u genoeg.

Niet alleen PHP: helaas ook Node.js, Java en technische certificaten

PHP2Shell kreeg de meeste aandacht, maar het was niet het enige incident van de week. Wie denkt “wij gebruiken geen PHP, dus wij zitten goed”, moet toch even verder lezen.

Node.js (21 oktober). Dit is de technologie achter veel modernere portalen en apps (dus ook zonder PHP). Het Node.js-project bracht dezelfde dag herstelversies uit voor tien fouten, waarvan vier ernstig. De zwaarste laat een aanvaller code uitvoeren via een fout in het uitpakken van gecomprimeerde gegevens; twee andere maken het mogelijk om beveiligde verbindingen naar een verkeerde server te laten gaan. Veilige versies: 26.12.1, 24.22.1 en 22.23.4 (Cybersecurity News). Node.js 20 en 25 krijgen geen pleister meer en moeten vervangen worden (Linux Compatible).

Java (20 en 21 oktober). Java zit vaak dieper in logistieke software verstopt: in WMS- en TMS-pakketten, EDI-koppelingen, douanesoftware en barcode scanners. Oracle bracht op 20 oktober zijn kwartaalupdate uit met 55 herstellingen voor Java alleen, en stuurde een dag later een aparte noodwaarschuwing na voor CVE-2026-91403, een fout in de beveiligde-verbindingslaag van Java die vanop afstand en zonder wachtwoord misbruikt kan worden (score 9,1 op 10). Getroffen zijn onder meer Java 8 update 511, 11.0.33, 17.0.21, 21.0.13 en 25.0.5 en alles daarvoor (Oracle).

Het certificaat-incident (17 tot 27 oktober). Dit is het minst zichtbare, en voor logistiek misschien het sluipendste. Elke beveiligde verbinding (het slotje in uw browser) steunt op certificaten die uitgereikt worden door een beperkt aantal vertrouwde instanties, de certificate authorities (CA). Op 17 oktober ontdekte een onderzoeker dat acht tussen certificaten van de Indiase uitgever eMudhra (merknaam emSign) gemaakt waren met zwakke sleutels: iedereen kon de geheime sleutel in minder dan een seconde terugrekenen, en dus valse certificaten maken voor eender welke website. Chrome, Firefox, Apple en Microsoft blokkeerden ze binnen enkele dagen; Chrome verwijdert het bijhorende hoofdcertificaat volledig op 27 oktober (Google).

Actuele browsers hebben beschermingsmaatregelen ontvangen; voor verouderde of afgesloten systemen moet dat afzonderlijk worden nagegaan. Maar in de logistiek draaien veel systemen die niet op het internet aangesloten zijn, of die maar zelden bijgewerkt worden: magazijnterminals, scanners, oudere EDI-boxen, software op een machine in de loods. Die hebben hun eigen lijstje van vertrouwde uitgevers, en dat lijstje wordt niet vanzelf aangepast of ververst. Zo’n systeem aanvaardt vandaag nog certificaten die het niet meer mag aanvaarden. Een vraag voor uw netwerkmensen dus: welke van onze interne systemen hebben een eigen certificaatlijst, en is emSign daar al uit verwijderd?

Wat vraagt u deze week aan uw IT-mensen of leverancier?

U hoeft de techniek niet te begrijpen om de juiste vragen te stellen. Stuur deze lijst door en vraag een antwoord per punt, met datum.

• Website en portalen: draaien ze op PHP, en zo ja, op welke versie? Is die 8.2.35, 8.3.36, 8.4.27 of 8.5.12 of hoger? Wanneer is de update uitgevoerd en is de server herstart?
• Oude versies: draait er nog ergens PHP 8.1 of ouder? Zo ja: wat is het plan en de datum om te migreren, en staat er intussen een firewall zoals Cloudflare voor?
• Webshop of klantenportaal bij een externe partij: heeft die partij schriftelijk bevestigd dat haar PHP bijgewerkt is?
• Node.js-toepassingen: op versie 26.12.1, 24.22.1 of 22.23.4 of hoger? Draait er nog Node.js 20 of 25?
• Java: welke software bij ons gebruikt Java (WMS, TMS, EDI, douane, scanners)? Is de Java-update van 21 oktober toegepast, of heeft de leverancier een datum gegeven?
• Certificaten: welke interne of afgesloten systemen hebben een eigen lijst van vertrouwde certificaatuitgevers, en is emSign/eMudhra daar al uit verwijderd?
• [ ] Inventaris: bestaat er een actuele lijst van alles wat bij ons aan het internet hangt, met de software en versie erop? Zo niet, is dit het moment om die te maken.

De laatste vraag is eigenlijk de belangrijkste. Wie geen inventaris heeft, kan bij het volgende incident, en dat komt er, opnieuw niet zeggen of hij geraakt is.

Laat een AI-assistent uw inventaris toetsen

Hebt u een lijst van wat er bij u draait, zelfs een rommelige Excel of een oud Word-document van uw vorige IT-leverancier? Dan kunt u die samen met de tekst hieronder aan een AI-assistent (Claude, ChatGPT, Copilot) voorleggen. U krijgt in mensentaal terug wat er bij u mogelijk geraakt is en welke vragen u moet stellen.

Eén waarschuwing vooraf: geef zo’n assistent nooit rechtstreeks toegang tot uw servers, wachtwoorden of beheerdersaccounts. U lost dan het ene probleem op door een ander te openen. Een lijst doorsturen is prima; sleutels doorgeven niet.

Hebt u geen inventaris? Geef dan gewoon de adressen van uw website, webshop en klantenportaal op. Een assistent met internettoegang kan aan de buitenkant soms aanwijzingen vinden over het gebruikte systeem of framework; de PHP-versie is doorgaans niet betrouwbaar publiek vast te stellen, en vertelt u anders hoe u dat zelf nakijkt. Kopieer dit, vul de adressen en eventueel uw lijst in, en stuur het door:

Kopieer onderstaande voorbeeldprompt en pas de adressen en inventaris aan:

You are helping a non-technical manager at a logistics company assess exposure to the security incidents of 17–22 October 2026. Report in plain Dutch. Do not ask for or suggest giving you any credentials, admin accounts or server access; work only from public information and the list below.

Step 1 — Fingerprint our public web interfaces.
For each URL under "Public web interfaces", determine as far as publicly observable: operating system, web server (Apache, nginx, IIS, LiteSpeed…), server-side runtime (PHP, Node.js, Java, .NET, other) and its version, CMS or framework (WordPress, Joomla, Drupal, Magento, PrestaShop, WooCommerce, Symfony, Laravel, Next.js…) and its version, hosting panel (Plesk, cPanel), whether it sits behind Cloudflare or another WAF, and which certificate authority issued its TLS certificate. If you can browse, inspect response headers, HTML source, well-known paths and the certificate. If you cannot browse, say so and give me the exact steps or free tools (e.g. a technology-profiler browser extension, an SSL checker) to find each item myself, plus the one-line question to send to the hosting company.

Step 2 — Compare everything (Step 1 results plus the inventory) against these incidents:
1. PHP "PHP2Shell" — CVE-2026-109618 and CVE-2026-109619, critical (CVSS 9.2), unauthenticated remote code execution. Affects all PHP from 5.4 onward. Fixed in PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. PHP 8.1, 8.0 and 7.4 have only limited source backports (vendor must build them); older versions have no fix. Affected platforms include WordPress, Joomla, Drupal, Magento/Adobe Commerce, PrestaShop, WooCommerce, Symfony, Laravel, Plesk and any custom PHP portal. A WAF (e.g. Cloudflare) is a stop-gap, not a fix.
2. Node.js security release of 21 October 2026 — 10 CVEs incl. CVE-2026-111497 (Brotli decoder RCE) and TLS hostname bypasses CVE-2026-105483 / CVE-2026-106069. Fixed in Node.js 26.12.1, 24.22.1, 22.23.4. Node.js 20 and 25 are end-of-life and receive no fix.
3. Oracle Java — Critical Patch Update of 20 October 2026 (55 Java SE fixes) plus Security Alert CVE-2026-91403 of 21 October 2026 (JSSE, CVSS 9.1, remote, no authentication). Affected: Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1 and earlier; GraalVM 17.0.21, 21.0.13, EE 21.3.20.
4. eMudhra / emSign CA key compromise — eight intermediate CA certificates with recoverable private keys, revoked 18–19 October 2026; root "emSign ECC Root CA - G3" removed by Mozilla on 20 October and by Chrome on 27 October 2026. Risk: any system with its own trust store (air-gapped, embedded, scanners, EDI boxes, old Java keystores, Linux ca-certificates) that has not removed these may still accept forged certificates, and any site whose certificate chains to emSign will break in browsers.

Step 3 — Output. One table with a row per URL and per inventory item: platform/runtime, version (observed or unknown), internet-facing or internal, verdict (affected / not affected / unknown), and the one question to send to the owner or supplier. End with a prioritised to-do list, most urgent first.

Public web interfaces (website, webshop, customer portal, track-and-trace, API):
- https://(uw website)
- https://(uw webshop of portaal)

Inventory (optional, paste whatever you have):
(plak hier uw lijst, of laat leeg)

De tekst staat in het Engels omdat de assistenten daar het best op reageren; het antwoord vraagt u in het Nederlands. Hebt u helemaal geen lijst? Begin dan met de assistent te vragen welke vragen u aan uw leverancier moet stellen om er een te maken. Dat is, na deze week, geen overbodige luxe meer.