Log4j JDBC Appender RCE (CVE-2021-44832)

On December 28, 2021, Apache disclosed the fourth remote code execution vulnerability found in Log4j2 within a three-week span. CVE-2021-44832 affects the framework's JDBC Appender: an attacker who can modify a Log4j2 configuration file is able to configure a DataSource referencing a JNDI URI, which Log4j2 will resolve and use to fetch and deserialize a remote object — resulting in arbitrary code execution on the host. It is the least severe of the Log4j2 "December 2021 cluster" of CVEs, but it is a real, exploitable RCE, and it landed while security teams were still triaging Log4Shell, meaning many organizations either never patched for it or unknowingly assumed their Log4Shell fix covered it. It didn't.

What the vulnerability actually does

Log4j2's JDBC Appender lets administrators route log records into a relational database. To do that, it needs a DataSource, and Log4j2 supports resolving that DataSource through a JNDI lookup — the exact same lookup-and-deserialize mechanism that made CVE-2021-44228 (Log4Shell) so dangerous. If an attacker can influence the appender's configuration to point at an attacker-controlled JNDI/LDAP/RMI endpoint, Log4j2 will happily connect out, fetch a serialized Java object, and deserialize it — the classic gadget-chain path to RCE.

The key difference from Log4Shell is the prerequisite: Log4Shell could be triggered by an unauthenticated attacker simply getting a crafted string into any logged input (a User-Agent header, a username field, etc.). CVE-2021-44832 requires the attacker to already have write access to the Log4j2 configuration file itself (log4j2.xml, .json, .yaml, or .properties). That's a meaningfully higher bar — it typically implies an attacker who has already achieved some foothold (compromised CI/CD pipeline, exposed config management system, insecure file share, or a lower-privileged account with unexpected write access to app config) and is using this bug to escalate that foothold into full code execution. It is a real chained-attack primitive, not a "drive-by" internet-facing bug.

Affected versions and components

• Affected: Apache Log4j2 versions 2.0-beta7 through 2.17.0, on all Java 8 (and later) builds.
• Not affected in the same way: The Java 7 line was patched separately in 2.12.4, and the Java 6 line in 2.3.2, both released alongside the fix.
• Fixed in: Log4j2 2.17.1 (Java 8+), 2.12.4 (Java 7), and 2.3.2 (Java 6).
• Root cause component: org.apache.logging.log4j.core.appender.db.jdbc — specifically the JDBC Appender's handling of DataSource JNDI resolution.
• Not required for exploitation: log4j2.formatMsgNoLookups, log4j2.enableJndi, or removing JndiLookup.class — the mitigations that stopped Log4Shell do not fully close this path, because the vulnerable code path is in the JDBC Appender's own JNDI handling, separate from the message-lookup substitution mechanism.
• This is important operationally: teams that "fixed Log4j" by pinning 2.16.0 or 2.17.0, or by stripping the JndiLookup class from their JARs, are still exposed to CVE-2021-44832 unless they specifically upgraded to 2.17.1+.

Severity, exploitability, and KEV status

Apache and NVD both scored CVE-2021-44832 at CVSS 3.1 base score 6.6 (Medium), a stark contrast to Log4Shell's 10.0 and CVE-2021-45046's 9.0. The lower score reflects the attack complexity: it requires an attacker to already control (or be able to modify) the application's logging configuration, which most vulnerability scoring frameworks treat as a significant precondition (high privileges required, low attack complexity given that precondition).

From an exploitation-likelihood standpoint, EPSS scoring for CVE-2021-44832 has consistently sat well below its Log4Shell sibling — reflecting the fact that mass, unauthenticated internet scanning can't trigger it. That doesn't mean exploitation probability is zero: config-write access is a common outcome of supply-chain compromises, over-permissioned CI service accounts, and insecure infrastructure-as-code pipelines, all of which are increasingly common attack paths.

CVE-2021-44832 has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, unlike CVE-2021-44228 and CVE-2021-45046, which were added within days of disclosure due to observed mass exploitation. The absence from KEV is consistent with its exploitation profile (secondary/chained rather than primary/internet-facing) but should not be read as "safe to ignore" — KEV tracks confirmed in-the-wild exploitation, not theoretical risk, and this bug remains a legitimate privilege-escalation and lateral-movement vector once an attacker has any config-write foothold.

Timeline

• December 9, 2021 — CVE-2021-44228 (Log4Shell) publicly disclosed; mass internet exploitation begins within hours.
• December 14, 2021 — CVE-2021-45046 disclosed after the initial 2.15.0 patch is found to be incomplete under non-default configurations.
• December 18, 2021 — CVE-2021-45105 (uncontrolled recursion / DoS via self-referential lookups) disclosed, fixed in 2.17.0.
• December 28, 2021 — CVE-2021-44832 disclosed by the Apache Logging Services team, credited to security researcher Yaniv Nizry (Checkmarx). Fixed versions 2.17.1, 2.12.4, and 2.3.2 released same day.
• January 2022 onward — Security vendors and researchers publish guidance clarifying that CVE-2021-44832 is not mitigated by the JndiLookup-removal workaround used for Log4Shell, prompting a second wave of remediation advisories.
• Ongoing — Because it was the fourth disclosure in under three weeks, CVE-2021-44832 remains one of the most commonly missed patches in Log4j remediation efforts audited during 2022–2023, and legacy/vendored copies of Log4j2 in third-party appliances and enterprise software continue to surface it in assessments today.

Remediation steps

1. Upgrade, don't just mitigate. Update to Log4j2 2.17.1 or later (2.12.4 for Java 7, 2.3.2 for Java 6). Configuration-based mitigations for Log4Shell (disabling message lookups, stripping JndiLookup.class) do not remediate this CVE — treat it as a separate patch requirement even if you already "fixed Log4j."
2. Inventory every copy of log4j-core, not just your direct dependency. Log4j2 is frequently shadowed or vendored inside third-party libraries, application servers, monitoring agents, and commercial appliances. A dependency-manifest scan alone will miss instances bundled inside fat JARs, WARs, or container base images. Use binary/artifact scanning (e.g., class-file hash matching) in addition to manifest parsing.
3. Lock down write access to logging configuration. Since exploitation requires config-write access, audit who and what (CI/CD service accounts, config-management tools, deployment pipelines, writable shared filesystems) can modify log4j2.xml/json/yaml/properties in production. Treat these files with the same access controls as application secrets.
4. Restrict outbound JNDI/LDAP/RMI traffic from application hosts. Egress filtering that blocks outbound LDAP/RMI callouts from app servers (except to explicitly allow-listed internal directories) blunts this vulnerability class generally, including any future JNDI-adjacent issues.
5. Re-verify JDBC Appender usage specifically. If your logging configuration uses a JDBC Appender with a JNDI-resolved DataSource, confirm the JNDI resource is defined in a tightly controlled context (e.g., an application-server-managed JNDI context that itself can't be redirected by config edits) rather than a raw/dynamic lookup.
6. Re-scan after remediation. Because this CVE hides behind an "already fixed Log4j" assumption, re-run SCA/SBOM-based scans post-remediation specifically checking resolved version numbers (2.17.1+/2.12.4+/2.3.2+), not just the presence of earlier mitigations.

How Safeguard Helps

Safeguard's SBOM generation and ingest pipeline surfaces every instance of log4j-core across your codebases, containers, and third-party artifacts — including vendored and shadowed copies that manifest-only scanners miss — and flags any version below 2.17.1/2.12.4/2.3.2 against CVE-2021-44832 automatically. Our reachability analysis then determines whether the vulnerable JDBC Appender code path is actually loadable and configurable in your deployed application, so your team can prioritize instances where the attack precondition (config-write exposure) is realistic over instances where the dependency is present but functionally dormant. Griffin AI correlates that reachability signal with your CI/CD and infrastructure permissions data to highlight where config-write access genuinely exists — the specific precondition this CVE requires — turning a generic "you have Log4j2" alert into an actionable, prioritized finding. When remediation is confirmed necessary, Safeguard can open an auto-fix pull request that bumps the dependency to a patched release and validates the build, closing the gap between detection and remediation without manual triage. For a vulnerability that's easy to assume is "already handled" because of Log4Shell fatigue, that combination of precise detection, exploitability context, and automated remediation is exactly what prevents it from lingering unpatched in production.