Kort gezegd: PHP2Shell en Log4Shell hebben gemeen dat het kritieke lekken zijn in een zeer wijdverbreide basisbouwsteen, waarmee aanvallers zonder aanmelding code kunnen uitvoeren. Ze verschillen in zichtbaarheid, indeling en de situatie bij bekende aanvallen. De belangrijkste les uit Log4Shell geldt vandaag onverminderd: wie weet waar de getroffen bouwsteen draait, handelt in uren in plaats van weken.
Waarom de vergelijking nu overal opduikt
In december 2021 hield Log4Shell de IT-wereld weken in zijn greep. Het BSI (de Duitse federale dienst voor informatiebeveiliging) riep toen het hoogste waarschuwingsniveau Rood uit. Bijna vijf jaar later valt bij PHP2Shell in veel bijdragen dezelfde naam, vaak met de vraag: „Wordt dit weer zo erg?”
De vergelijking ligt voor de hand, en ze is nuttig als men haar juist voert. Ze laat zien welke patronen zich herhalen en welke ervaringen bedrijven vandaag direct kunnen gebruiken. Hoe het BSI de huidige situatie indeelt, legt de bijdrage BSI-waarschuwingsniveau Oranje uit.
PHP2Shell en Log4Shell rechtstreeks vergeleken
| Kenmerk | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Getroffen software | Java-bibliotheek Log4j | de PHP-runtime zelf |
| Kenmerk | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Beoordeling | CVSS 10.0 (v3) | CVSS v4.0 9.2 |
| Werking | code-uitvoering zonder aanmelding | code-uitvoering zonder aanmelding |
| BSI-waarschuwingsniveau | 4 / Rood | 3 / Oranje |
| Situatie bij waarschuwing | volgens toenmalige berichten compromitteringen bekend | aanvalspogingen gemeld, volgens het BSI aanvankelijk geen bevestigde geslaagde aanvallen op grote schaal |
| Zichtbaarheid | vaak diep in toepassingen verborgen | zichtbaar op de server, patchstatus door backports echter moeilijk af te lezen |
| Vervolgmeldingen | meerdere andere CVE's binnen enkele weken | aanwijzing over CVE-2026-115560 op 23 oktober |
Wat de twee lekken gemeen hebben
Eén basisbouwsteen, ontelbare toepassingen. Log4j zat in Java-software van allerlei aard, PHP draagt WordPress, Shopware, TYPO3 en talloze eigen ontwikkelingen. In beide gevallen is niet één product getroffen, maar een fundament.
Geen login nodig. Beide lekken maken uitvoering van code op afstand zonder aanmelding mogelijk. Dat maakt ze aantrekkelijk voor geautomatiseerde aanvallen.
De patch is niet het einde. Bij Log4Shell bleek dat veel systemen vóór de update al waren aangevallen. Ook bij PHP2Shell geldt: een patch verwijdert geen binnengebrachte schadelijke software. Volgens mediaberichten werd al op 17 oktober een eerste aanvalspoging waargenomen.
Vervolgmeldingen. Na Log4Shell verschenen binnen enkele weken meer CVE's over Log4j. Bij PHP kwam twee dagen na de patches de aanwijzing over CVE-2026-115560. Waarom meer meldingen waarschijnlijk zijn, legt Na PHP2Shell: waarom meer meldingen waarschijnlijk zijn uit.
Waar de vergelijking mank gaat
Het grootste verschil zit in de zichtbaarheid. Log4j was vaak ingebouwd als onderdeel van een toepassing, soms meervoudig genest. Veel beheerders wisten eenvoudig niet dat ze het gebruikten. PHP daarentegen is op een webserver geen geheim. Daar staat tegenover dat bij PHP2Shell een andere onduidelijkheid ontstaat: distributies en hostingproviders spelen correcties als backport in, het getoonde versienummer blijft gelijk. Men ziet PHP, maar niet direct of het gepatcht is.
Een tweede verschil is de uitgangssituatie bij de update. Bij Log4Shell moesten fabrikanten van vakspecifieke toepassingen vaak eerst nieuwe versies leveren. Bij PHP2Shell staan updates voor alle ondersteunde takken klaar. Lastig wordt het bij PHP 8.1 en ouder, waarvoor het PHP-project geen officiële updates meer publiceert.
Een derde verschil betreft de plek van de aanval. Bij Log4Shell kon elke plek gevaarlijk zijn waar een toepassing invoer registreerde, dus ook interne systemen die slechts indirect gegevens van het internet kregen. Bij PHP2Shell staat de webserver centraal, die verzoeken rechtstreeks aanneemt. Dat maakt het zoeken naar getroffen systemen iets overzichtelijker: eerst alle openbaar bereikbare PHP-diensten, daarna interne toepassingen.
Ten slotte verschilt de situatie bij het misbruik. Voor Log4Shell circuleerden al vroeg eenvoudige aanvalstools, en compromitteringen waren volgens toenmalige berichten al op het moment van de waarschuwing bekend. Bij PHP2Shell melden Cloudflare en Patchstack aanvalspogingen, watchTowr heeft een van de lekken naar eigen zeggen nagebootst, bevestigde geslaagde aanvallen op grote schaal meldde het BSI aanvankelijk niet. Dat kan veranderen. Het is wel een reden waarom de vergelijking niet als prognose deugt.
Gebruik de ervaringen met Log4Shell in uw eigen huis: welke lijsten, werkwijzen en contacten hebben toen geholpen? Veel daarvan is direct bruikbaar voor PHP2Shell.
Vijf lessen uit Log4Shell die vandaag helpen
- Inventaris vóór patch: Wie in 2021 een actuele lijst van zijn systemen had, was sneller. Dat geldt vandaag net zo. Een handleiding biedt de bijdrage Inventaris van alle websites en servers.
- Afhankelijkheden kennen: Een stuklijst van de softwarebouwstenen, kort SBOM, beantwoordt de vraag „Waar gebruiken we dit?” in minuten. Voor PHP-toepassingen helpt een blik in Composer, zoals Composer-afhankelijkheden controleren beschrijft.
- Logs bewaren: Na Log4Shell konden veel bedrijven niet meer vaststellen of ze getroffen waren, omdat logs ontbraken. De vakpers adviseert bij PHP2Shell logs vanaf 20 oktober veilig te stellen.
- Achteraf controleren: Een patch beantwoordt niet wat er eerder gebeurde. Een controle op sporen hoort erbij.
- Op vervolgmeldingen voorbereid zijn: De eerste update is zelden de laatste. Wie de updateroute eenmaal netjes heeft ingericht, herhaalt haar snel.
Hoe helpt PHP SOS concreet?
- Inventarisatie: Wij stellen vast waar PHP in uw bedrijf draait, in welke versie en uitvoeringsmodus.
- Patch en herstart: Wij spelen updates in en leggen de status per systeem vast.
- Sporencontrole: Wij stellen logs veilig en controleren op bijzonderheden sinds 17 oktober.
- Doorlopende monitoring: Wij houden uw systemen in het oog, zodat vervolgmeldingen niet weer bij nul beginnen.
Hoe de doorlopende bewaking eruitziet, beschrijft Security-monitoring voor webservers.
Conclusie
PHP2Shell is niet Log4Shell, maar het rijmt erop. Beide treffen een fundament, beide vragen meer dan één patch. Bedrijven die uit 2021 inventaris, logbewaring en updateroutes hebben meegenomen, hebben vandaag een voorsprong. Voor alle anderen is nu het moment om dat in te halen.
Veelgestelde vragen
Is PHP2Shell net zo erg als Log4Shell?
Beide zijn kritieke lekken in zeer wijdverbreide software waarmee aanvallers zonder aanmelding code kunnen uitvoeren. Het BSI deelde Log4Shell in 2021 in op Rood, PHP2Shell op Oranje. Een belangrijk verschil: bij Log4Shell waren volgens toenmalige berichten bij de waarschuwing al compromitteringen bekend, bij PHP2Shell volgens het BSI aanvankelijk geen bevestigde geslaagde aanvallen op grote schaal.
Wat was Log4Shell?
Log4Shell was een kritiek lek in de Java-bibliotheek Log4j, dat in december 2021 bekend werd en onder CVE-2021-44228 wordt geregistreerd. Log4j zat als bouwsteen in zeer veel toepassingen, vaak zonder dat beheerders het wisten.
Komen er na PHP2Shell nog meer lekken?
Dat is mogelijk. Na Log4Shell volgden binnen enkele weken meer CVE's over Log4j. Bij PHP was er op 23 oktober al een aanwijzing over CVE-2026-115560, die alleen bij ongebruikelijke configuratie werkt. Houd rekening met vervolgmeldingen.
Wat is een SBOM?
Een Software Bill of Materials is een stuklijst van alle softwarebouwstenen waaruit een toepassing bestaat. Daarmee is bij een nieuw lek snel vast te stellen waar de getroffen bouwsteen wordt gebruikt.