CVE-2022-23305 — log4j
CRITICALCVE-2022-23305 is a critical-severity (CVSS 9.8) SQL Injection vulnerability in log4j:log4j. 4 public exploit references exist, so weaponization risk is real. No vendor fix is recorded yet; mitigation options are listed below.
SQL injection in JDBC Appender in Apache Log4j V1
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- 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 CVE-2022-23305.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2022-23305 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,738 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
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. 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 suiteoracleResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & 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 CVE-2022-23305 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
Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.
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 issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Red Hat Satellite bundles log4j-over-slf4j with Candlepin, however, product is not affected as it uses logback framework for logging. Red Hat Virtualization and OpenShift Container Platform in the OCP…
These are the possible mitigations for this flaw for releases version 1.x: - Comment out or remove JDBCAppender in the Log4j configuration if it is used - Remove the JDBCAppender class from the server's jar files. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/jdbc/JDBCAppender.class ```Source: Red Hat security advisory for CVE-2022-23305 (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 CVE-2022-23305 in your dependencies?
Find it across Maven, including transitive dependencies.