CVE-2019-14540: Jackson-databind blacklist bypass via c3p...

FasterXML's jackson-databind has spent years fighting a losing game of whack-a-mole against deserialization gadget chains, and CVE-2019-14540 is one more entry in that ledger. The flaw lets an attacker who can influence JSON passed into jackson-databind's polymorphic (default) typing achieve remote code execution by smuggling in classes from the c3p0 JDBC connection-pooling library — specifically com.mchange.v2.c3p0.WrapperConnectionPoolDataSource and related c3p0 JNDI-referencing classes. Those classes can be coerced into performing a JNDI lookup against an attacker-controlled server, which in turn can return a malicious object and hand the attacker code execution on the deserializing host.

The vulnerability isn't a new class of bug — it's a bypass. Jackson-databind ships a hardcoded denylist of "known-bad" classes that it refuses to instantiate during polymorphic deserialization, precisely because so many popular Java libraries contain classes usable as RCE gadgets. CVE-2019-14540 simply proves that c3p0's classes weren't on that list yet, giving attackers a working path around the mitigation. This pattern — researchers finding one more library not yet blacklisted, FasterXML patching it, researchers finding the next one — defined roughly two years of the jackson-databind CVE backlog and is exactly why blacklist-based deserialization defenses are treated skeptically by the security community today.

Affected versions and components

• jackson-databind 2.x before 2.9.10 is affected when an application enables polymorphic/default typing (enableDefaultTyping(), @JsonTypeInfo with broad visibility, or equivalent configuration) via ObjectMapper.
• The exploit further requires c3p0 (com.mchange:c3p0) to be reachable on the application's classpath, since the gadget chain pivots through c3p0's WrapperConnectionPoolDataSource / JNDI-referencing data source classes.
• As with the rest of this CVE family, exploitation is conditional, not universal: an application using jackson-databind's safe default (non-polymorphic) typing, or one that never loads c3p0, is not exploitable via this specific gadget — though it may remain exposed to other gadget chains covered by separate CVEs in the same series (CVE-2019-12086, CVE-2019-12814, CVE-2019-14379, CVE-2019-14439, CVE-2019-16335, CVE-2019-16942, CVE-2019-16943, and others).
• FasterXML fixed the issue in jackson-databind 2.9.10, and — consistent with how the project handled this whole wave of gadget-bypass reports — backported the blacklist addition to the older 2.6.x, 2.7.x, and 2.8.x maintenance lines as well, since many enterprise Java applications were pinned to those branches and unable to jump straight to 2.9.x.

Because jackson-databind is a transitive dependency pulled in by Spring Boot, countless REST frameworks, and any project touching jackson-core/jackson-databind for JSON (de)serialization, the practical exposure surface for this CVE is less "do I use jackson-databind" and more "do I use it with default typing enabled, and is c3p0 anywhere in my dependency tree" — a question most teams cannot answer by memory and need a software composition analysis (SCA) tool or SBOM to answer with confidence.

CVSS, EPSS, and KEV context

NVD's entry for CVE-2019-14540 scores it in the High severity band under CVSS v3, consistent with the scoring pattern applied across this entire jackson-databind gadget-bypass series — network attack vector, no privileges or user interaction required, but elevated attack complexity reflecting the precondition that default typing must already be enabled and a vulnerable gadget library must be present on the classpath. That conditionality is also why these CVEs, despite scoring High, rarely produce the kind of internet-wide automated exploitation seen with unconditional deserialization bugs.

CVE-2019-14540 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. That's a meaningful signal: unlike headline deserialization incidents such as Log4Shell, there is no confirmed record of widespread in-the-wild exploitation of this specific c3p0 gadget bypass. That doesn't mean it's ignorable — proof-of-concept exploit code for jackson-databind gadget chains, including c3p0-based chains, has circulated publicly for years, and any environment matching the precondition (default typing + c3p0 on the classpath) should treat this as a live, reachable RCE path rather than a theoretical one. EPSS scoring for this CVE reflects the same nuance: exploitation likelihood is tied to configuration rather than being trivially universal, so teams should weigh EPSS alongside actual reachability analysis rather than treating a modest score as a reason to deprioritize the fix.

Timeline

The broader story here starts with CVE-2017-7525, the original jackson-databind polymorphic deserialization RCE, which prompted FasterXML to introduce the blacklist defense in the first place. Through 2018 and especially 2019, external researchers systematically worked through the universe of JDK and third-party libraries looking for classes that could serve as deserialization gadgets but weren't yet on Jackson's denylist — c3p0, among others, turned out to qualify. CVE-2019-14540 documents the c3p0-specific bypass discovered and reported in 2019. FasterXML's response followed its now-established playbook for this CVE family: add the newly reported gadget classes to the blacklist and cut a patch release. The fix shipped in jackson-databind 2.9.10, with corresponding backports to the 2.6.x, 2.7.x, and 2.8.x lines so organizations on older supported branches weren't forced into a disruptive major-version jump just to close the hole.

Remediation steps

1. Upgrade jackson-databind. Move to 2.9.10 or later (or the patched point release for your 2.6.x/2.7.x/2.8.x branch) so the c3p0 gadget classes are included in the built-in blacklist. Because this CVE is one of many in a series, don't treat 2.9.10 as a finish line — track FasterXML's advisories for the full run of jackson-databind gadget CVEs and keep the dependency current on an ongoing basis.
2. Stop relying on default/polymorphic typing where you can avoid it. enableDefaultTyping() and broad @JsonTypeInfo configurations are the actual root cause enabling this whole CVE family. Replace them with explicit, allow-listed type registration (@JsonTypeInfo scoped to a closed set of subtypes, or Jackson's PolymorphicTypeValidator introduced in 2.10+) so an attacker can't smuggle in arbitrary classes regardless of what's on the blacklist.
3. Audit your classpath for gadget-capable libraries. Even after patching jackson-databind, inventory whether c3p0 and other historically-abused libraries (commons-collections, spring-beans, xalan, etc.) are present as direct or transitive dependencies, and remove or isolate ones you don't actually need.
4. Constrain outbound JNDI and RMI where feasible. Since the c3p0 gadget chain pivots through a JNDI lookup, network egress controls that block application servers from making arbitrary outbound JNDI/LDAP/RMI connections reduce the blast radius even if a deserialization primitive is later found.
5. Generate and monitor an SBOM. This CVE is a textbook example of why transitive dependency visibility matters — most teams don't consciously "choose" to depend on c3p0; it arrives via a JDBC connection pool three layers down the dependency graph.

How Safeguard Helps

CVE-2019-14540 is a good illustration of why supply chain security has to go deeper than "check if jackson-databind is patched." Safeguard continuously scans your build artifacts and dependency manifests to surface every version of jackson-databind in use across your services — including nested transitive copies pulled in by frameworks you didn't choose directly — and flags the specific fixed versions (2.9.10 and the backported 2.6.7.3/2.7.9.5/2.8.11.5-equivalent lines) you need to reach.

Because exploitability here hinges on configuration, not just version number, Safeguard's SBOM and dependency graph views also help you answer the harder question: is c3p0 actually reachable in the same service that enables polymorphic typing? That combination — precise version tracking plus dependency co-occurrence visibility — is what turns a generic "you have a vulnerable library" alert into an actionable, risk-ranked finding your team can prioritize with confidence. Pair that with Safeguard's continuous monitoring against newly disclosed CVEs in libraries like jackson-databind, and you get an early warning the next time a researcher finds one more gadget class the blacklist missed.