How severe is GHSA-jfh8-c2jp-5v3q?

GHSA-jfh8-c2jp-5v3q has a CVSS score of 10/10, rated CRITICAL. Immediate patching is strongly recommended.

Which packages are affected by GHSA-jfh8-c2jp-5v3q?

GHSA-jfh8-c2jp-5v3q affects the following packages: org.apache.logging.log4j:log4j-core (Maven), org.apache.logging.log4j:log4j-core (Maven), org.apache.logging.log4j:log4j-core (Maven), com.guicedee.services:log4j-core (Maven), org.xbib.elasticsearch:log4j (Maven), uk.co.nichesolutions.logging.log4j:log4j-core (Maven), org.ops4j.pax.logging:pax-logging-log4j2 (Maven), org.ops4j.pax.logging:pax-logging-log4j2 (Maven), and 2 more. Ecosystems affected: Maven.

How do I fix GHSA-jfh8-c2jp-5v3q?

Update org.apache.logging.log4j:log4j-core to version 2.15.0 or later. Run your dependency manager's update command and verify no transitive dependencies pin the vulnerable version. Use O3 Security's SCA scanner to confirm the fix is applied across your entire dependency tree.

Is GHSA-jfh8-c2jp-5v3q actively exploited in the wild?

Yes. There are 379 known exploit references for GHSA-jfh8-c2jp-5v3q, including 3 documented proof-of-concept exploits on Exploit-DB and 50 in-the-wild exploitations observed on GitHub and other sources. Treat this as actively exploitable and prioritize patching immediately. All exploit code should only be run in an isolated sandbox environment for research or authorized testing — never against production systems without explicit written authorization.

What is the EPSS score for GHSA-jfh8-c2jp-5v3q?

GHSA-jfh8-c2jp-5v3q has an EPSS (Exploit Prediction Scoring System) score of 94.4%, placing it in the 100th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. A score above 50% indicates significantly elevated exploitation risk — immediate patching is strongly recommended.

Is GHSA-jfh8-c2jp-5v3q in the CISA Known Exploited Vulnerabilities catalog?

Yes. GHSA-jfh8-c2jp-5v3q (Apache Log4j2 Remote Code Execution Vulnerability) was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on 2021-12-10. CISA required all US federal civilian agencies to remediate this vulnerability by 2021-12-24. The required action was: For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. Temporary mitigations using one of the measures provided at https://www.cisa.gov/uscert/ed-22-02-apache-log4j-recommended-mitigation-measures are only acceptable until updates are available. This CVE has been used in known ransomware campaigns. Being listed in the KEV catalog is the strongest possible confirmation of active exploitation — treat this as a critical priority.

What type of vulnerability is GHSA-jfh8-c2jp-5v3q?

GHSA-jfh8-c2jp-5v3q is classified as Improper Input Validation (CWE-20), Uncontrolled Resource Consumption (CWE-400), Deserialization of Untrusted Data (CWE-502), Expression Language Injection (CWE-917). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

Is there exploit tooling available for GHSA-jfh8-c2jp-5v3q?

A Nuclei detection template exists for GHSA-jfh8-c2jp-5v3q, meaning automated scanners can fingerprint it. Public exploit tooling significantly increases real-world risk — prioritize patching and ensure detection coverage. Exploit tooling should only ever be used in isolated, authorized testing environments.

When was GHSA-jfh8-c2jp-5v3q published, and has it been updated?

GHSA-jfh8-c2jp-5v3q was published on December 10, 2021 and was last updated on October 22, 2025. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

CISA KEV·Added 2021-12-10 — agencies required to remediate by 2021-12-24 · Ransomware

☕ Maven

GHSA-jfh8-c2jp-5v3q

CRITICAL

Remote code injection in Log4j

Also known asCVE-2021-44228

Published

Dec 10, 2021

Updated

Oct 22, 2025

Affected

10 pkgs

Patched

7 / 10

Exploits

379 known

EPSS Exploitation Probability

via FIRST.org ↗

94.4%probability of exploitation in next 30 days

Very High Risk100th percentile0.00%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

10 pkgs affected

☕org.apache.logging.log4j:log4j-core☕org.apache.logging.log4j:log4j-core☕org.apache.logging.log4j:log4j-core☕com.guicedee.services:log4j-core☕org.xbib.elasticsearch:log4j☕uk.co.nichesolutions.logging.log4j:log4j-core☕org.ops4j.pax.logging:pax-logging-log4j2☕org.ops4j.pax.logging:pax-logging-log4j2+2 more

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.

Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.

Impact

Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.

Affected versions

Any Log4J version prior to v2.15.0 is affected to this specific issue.

The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.

Security releases

Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3

Affected packages

Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.

Remediation Advice

Updated advice for version 2.16.0

The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.

Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.

Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.

Affected Packages

10 total 7 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`org.apache.logging.log4j:log4j-core`	≥ 2.13.0&&< 2.15.0	2.15.0
☕Maven	`org.apache.logging.log4j:log4j-core`	≥ 2.0-beta9&&< 2.3.1	2.3.1
☕Maven	`org.apache.logging.log4j:log4j-core`	≥ 2.4&&< 2.12.2	2.12.2
☕Maven	`com.guicedee.services:log4j-core`	all versions	No fix
☕Maven	`org.xbib.elasticsearch:log4j`	all versions	No fix
☕Maven	`uk.co.nichesolutions.logging.log4j:log4j-core`	all versions	No fix

Exploits & PoCs

379

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

EDB-51183remotejava

AD Manager Plus 7122 - Remote Code Execution (RCE)

by Chan Nyein Wai · Apr 1, 2023

Exploit-DB Source

EDB-50592remotejava

Apache Log4j 2 - Remote Code Execution (RCE)

by kozmer · Dec 14, 2021

Exploit-DB Source

EDB-50590remotejava

Apache Log4j2 2.14.1 - Information Disclosure

by leonjza · Dec 14, 2021

Exploit-DB Source

Frequently Asked Questions

# Summary Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per [Apache's Log4j security guide](https://logging.apache.org/log4j/2.x/security.html): Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled b

O3 Security · Impact-Aware SCA

Is GHSA-jfh8-c2jp-5v3q in your stack?

O3 detects GHSA-jfh8-c2jp-5v3q across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my stack How O3 SCA works