Deserialization of Untrusted Data in Log4j 1.xGHSA-w9p3-5cr8-m3jj
HIGHGHSA-w9p3-5cr8-m3jj is a high-severity (CVSS 8.8) Deserialization of Untrusted Data vulnerability in log4j:log4j. EPSS puts its 30-day exploitation probability at 63.6% (99th percentile). No vendor fix is recorded yet; mitigation options are listed below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-w9p3-5cr8-m3jj.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-w9p3-5cr8-m3jj by exploitation likelihood (EPSS) against impact (CVSS). In the shaded patch-first corner (EPSS 50%+, CVSS 7.0+).
Where this sits among everything scored
Of 385,987 CVEs with a current EPSS score, this one falls in the 50–90% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
log4j:log4j☕org.zenframework.z8.dependencies.commons:log4j-1.2.17Real-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
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | log4j:log4j | all versions | No fix |
| ☕Maven | org.zenframework.z8.dependencies.commons:log4j-1.2.17 | all versions | No fix |
Affected Products
log4japachebrocade sannavbroadcomsnapmanagernetappadvanced supply chain planningoraclebusiness intelligenceoraclebusiness process management suiteoracleDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for log4j:log4j, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of log4j:log4j has shipped for GHSA-w9p3-5cr8-m3jj yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Note this flaw ONLY affects applications which are specifically configured to use JMSSink, which is not the default, or when the attacker has write access to the Log4j configuration for adding JMSSink to the attacker's JNDI LDAP endpoint. Red Hat Satellite bundles log4j-over-slf4j with Candlepin, however, product is…
These are the possible mitigations for this flaw for releases version 1.x: - Comment out or remove JMSSink in the Log4j configuration if it is used - Remove the JMSSink class from the server's jar files. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/net/JMSSink.class ``` - Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.Source: Red Hat security advisory for GHSA-w9p3-5cr8-m3jj (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| EAP 6.4.24 release | see advisory | RHSA-2022:5458 |
| EAP 6.4 log4j async | log4j | RHSA-2022:0437 |
| Red Hat AMQ Streams 1.6.7 | see advisory | RHSA-2022:0467 |
| Red Hat AMQ Streams 2.0.1 | log4j | RHSA-2022:0469 |
| Red Hat Data Grid 7.3.9 | log4j | RHSA-2022:0430 |
| Red Hat Enterprise Linux 6 Extended Lifecycle Support | log4j-0:1.2.14-6.6.el6_10 | RHSA-2022:0442 |
| Red Hat Enterprise Linux 8 | parfait:0.5-8050020220124063900.6b489b78 | RHSA-2022:0290 |
| Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions | parfait:0.5-8010020220124232535.d5701770 | RHSA-2022:0294 |
Frequently Asked Questions
Is GHSA-w9p3-5cr8-m3jj in your dependencies?
Find it across Maven, including transitive dependencies.