CVE-2019-12814: Jackson-databind polymorphic type gadget ...

Lede

CVE-2019-12814 is a deserialization vulnerability in FasterXML's jackson-databind, the ubiquitous Java library that powers JSON binding for Spring Boot, countless REST APIs, and enterprise middleware. It belongs to the long-running family of jackson-databind polymorphic typing gadget issues: when an application enables "default typing" (or otherwise lets an attacker control the concrete Java type instantiated during deserialization) and untrusted JSON reaches that code path, an attacker can smuggle a reference to a gadget class already present on the classpath. Jackson then instantiates and partially initializes that class on the attacker's behalf, and if the gadget class has side effects in its constructor, static initializer, or setters, the result can range from denial of service and server-side request forgery to remote code execution, depending entirely on which gadget is reachable.

CVE-2019-12814 specifically extends jackson-databind's deny-list of unsafe classes to cover a gadget associated with JAXB (Java Architecture for XML Binding) tooling — the XML-binding runtime that ships alongside many enterprise Java frameworks and, in older JDKs, the JDK itself. As with every entry in this CVE series, the underlying design weakness (jackson-databind trusting a type identifier embedded in untrusted JSON) is the same; only the specific "gadget" being blocked changes from one advisory to the next.

Affected Versions and Components

• Component: com.fasterxml.jackson.core:jackson-databind
• Affected versions: jackson-databind releases prior to 2.9.9.1, the point release FasterXML shipped specifically to widen the internal class deny-list used to block known-dangerous gadget types.
• Precondition for exploitation: the vulnerability is only reachable when an application has explicitly enabled polymorphic type handling against untrusted input — commonly via ObjectMapper.enableDefaultTyping() or a permissive @JsonTypeInfo(use = Id.CLASS) / Id.MINIMAL_CLASS configuration — and a vulnerable JAXB-related class is present somewhere on the application's runtime classpath (pulled in transitively by an unrelated dependency, an application server, or the JDK's bundled JAXB implementation).
• Jackson-databind's own JSON parsing is not vulnerable by default; the risk is entirely a function of unsafe configuration combined with a reachable gadget class. Many real-world services never enable default typing and are unaffected regardless of the jackson-databind version they run.

CVSS, EPSS, and KEV Context

CVE-2019-12814 sits in the same severity tier as the dozens of other jackson-databind blacklist CVEs disclosed across 2017–2020: NVD scoring for this family generally lands in the Medium-to-High band, reflecting a network-exploitable vector offset by a High attack-complexity rating, since successful exploitation depends on both an unsafe application configuration and a specific gadget class being present. It is not the kind of "point and shoot" flaw that Log4Shell was.

Consistent with that dependency-specific nature, EPSS scoring (which post-dates this CVE's original disclosure but has since been backfilled) rates real-world exploitation likelihood for CVE-2019-12814 as low relative to marquee internet-wide vulnerabilities — mass, unauthenticated exploitation requires the coincidence of an exposed default-typing sink and the right gadget on the classpath, which is uncommon compared to how often jackson-databind itself is deployed. We are not aware of CVE-2019-12814 appearing on CISA's Known Exploited Vulnerabilities (KEV) catalog. That said, "low EPSS" is not "no risk": jackson gadget chains have been reliably weaponized in the past (notably CVE-2017-7525), and organizations running legacy default-typing configurations should not treat this as purely theoretical.

Timeline

• 2017: The jackson-databind polymorphic deserialization problem enters mainstream awareness with CVE-2017-7525, demonstrating that enableDefaultTyping() combined with a gadget class on the classpath yields remote code execution. FasterXML responds by maintaining an internal deny-list of known-dangerous classes rather than redesigning the typing model outright.
• 2017–2019: Security researchers continue discovering additional gadget classes in commonly bundled libraries (database connection pools, logging frameworks, templating engines, XML binding tooling, and more). Each newly identified gadget results in its own CVE and a corresponding jackson-databind point release that adds the class to the deny-list — a pattern the community began referring to as "whack-a-mole" patching.
• Mid-2019: CVE-2019-12814 is disclosed as part of this wave, addressing a JAXB-related gadget class. FasterXML ships jackson-databind 2.9.9.1 to block it, alongside sibling CVEs from the same period covering other gadget classes discovered around the same time.
• 2019 onward: Recognizing that blacklisting individual classes could never fully close the underlying design gap, the jackson-databind maintainers shift strategy: newer 2.10.x and later releases require applications to opt into an explicit PolymorphicTypeValidator allow-list when using default typing, rather than relying on an ever-growing deny-list. This structural change addresses the root cause far more durably than any single CVE fix.

Remediation Steps

1. Upgrade jackson-databind. At minimum, move past 2.9.9.1 to pick up the deny-list entry for this gadget. Better still, upgrade to a current 2.1x release where PolymorphicTypeValidator-based allow-listing is the default posture for polymorphic typing, since it structurally prevents the entire gadget-chasing pattern rather than patching one class at a time.
2. Audit for default typing usage. Search your codebase for enableDefaultTyping(), activateDefaultTyping(), and permissive @JsonTypeInfo(use = Id.CLASS) / Id.MINIMAL_CLASS annotations applied to types that ever deserialize untrusted input. Replace them with a scoped allow-list of expected types wherever possible.
3. Reduce gadget surface. Remove JAXB and other XML-binding dependencies from the runtime classpath if your application doesn't actually need them. Fewer "interesting" classes on the classpath means fewer usable gadgets, regardless of jackson-databind's own patch level.
4. Track transitive dependencies, not just direct ones. jackson-databind is frequently pulled in transitively through Spring Boot starters, application servers, and third-party SDKs. A pinned direct dependency doesn't guarantee a safe version is what actually loads at runtime.
5. Add compensating detection. Where immediate upgrades aren't feasible (e.g., vendored or end-of-life applications), monitor for anomalous deserialization behavior and restrict outbound network access from application servers to reduce the blast radius of SSRF-class gadgets.
6. Verify with an SBOM, not a changelog. Confirm the fix by generating a software bill of materials for each build artifact and container image and checking the resolved jackson-databind version directly, rather than trusting a dependency declaration in a manifest file.

How Safeguard Helps

CVE-2019-12814 is a textbook example of why point-in-time dependency audits fall short: it's one CVE among dozens in a multi-year gadget-chasing saga, jackson-databind is present almost everywhere in the Java ecosystem, and the actual exploitability hinges on application-level configuration that a version number alone can't reveal.

Safeguard continuously builds and verifies software bills of materials across your build pipeline and deployed artifacts, so every instance of jackson-databind — direct or transitive, in a monolith or buried three dependencies deep in a microservice — is inventoried automatically, with no manual dependency tree spelunking required. When a CVE like this one is disclosed (or, as here, retroactively re-examined), Safeguard flags every affected artifact by exact resolved version, not just what a pom.xml or build.gradle claims.

Because exploitability for this vulnerability class depends on configuration and reachability rather than presence alone, Safeguard's prioritization layer helps security and engineering teams focus remediation effort on services that actually enable polymorphic type handling against untrusted input, instead of forcing a blanket emergency upgrade across every service that merely has jackson-databind on the classpath. Policy gates in CI/CD can block builds that resolve to a vulnerable jackson-databind range, and drift detection alerts when a newly introduced transitive dependency reintroduces a patched version elsewhere in the stack.

Finally, because SBOM data is retained historically, Safeguard makes it straightforward to answer the question every security team eventually gets asked about a vulnerability like CVE-2019-12814: "were we ever exposed, and for how long?" — turning what would otherwise be an archaeological dig through years of build logs into a query against a continuously maintained, verifiable dependency graph.