Jackson-databind is the data-binding layer of the Jackson project — the library that turns JSON into Java objects and back. It is the default JSON engine in Spring Boot and countless other Java frameworks, and through those it reaches an enormous share of the Java ecosystem via Maven and Gradle. It is also the poster child for one of the longest-running vulnerability sagas in open source: a multi-year stream of remote-code-execution CVEs driven by a single dangerous feature, polymorphic deserialization.
The notable historical CVEs
Jackson-databind's CVE history is dominated by "deserialization gadget" advisories. When an application enables polymorphic type handling and then deserializes attacker-controlled JSON, an attacker can name a class on the classpath ("gadget") that executes code as a side effect of being constructed or configured. Real, published examples include:
- CVE-2017-7525 — the original default-typing remote code execution that opened the floodgates.
- CVE-2017-15095 — a further gadget bypass extending CVE-2017-7525.
- CVE-2018-7489 — a bypass of the blocklist that allowed RCE through additional gadget classes.
- CVE-2019-12384 — polymorphic deserialization RCE via a logback/JNDI gadget chain.
- CVE-2019-14540 / CVE-2019-14379 / CVE-2020-36189 — a representative slice of the dozens of individual gadget-class CVEs filed across 2019 and 2020 as new dangerous classes were discovered.
Later, the project also had denial-of-service issues: CVE-2020-25649 (an XML external entity issue in the XML dataformat) and CVE-2022-42003 / CVE-2022-42004, which allowed resource exhaustion through deeply nested or unconstrained input, fixed in the 2.13.4/2.12.7 line.
The lesson from that avalanche of gadget CVEs is that maintaining a blocklist of dangerous classes was a losing game — every patch was followed by a new gadget. The real fix was architectural.
Common misuse and risks
The root cause of almost every serious Jackson-databind incident is enabling default typing on data you do not fully control. Historically this looked like calling objectMapper.enableDefaultTyping() (now deprecated) so that Jackson would embed and honor Java type information (@class) in the JSON. That lets the sender of the JSON decide which Java classes get instantiated — which is exactly the capability a gadget attack needs.
Related risks:
- Deserializing untrusted JSON into overly broad types like
Objectorjava.util.Mapwith polymorphic handling on. - Running an old, pinned jackson-databind version transitively — it is a dependency of so many libraries that a stale copy easily hides in a build.
- Assuming "we only accept JSON, not Java serialization" makes you safe. The gadget CVEs are specifically about JSON.
How to use jackson-databind safely
Set the version floor: run a current, supported release — the 2.15.x or newer line, and at minimum 2.13.4.2/2.12.7.1 for the DoS fixes. Newer releases also default to safer behavior.
The critical configuration rules:
- Do not enable default typing globally. If you never call
activateDefaultTyping/enableDefaultTyping, the entire gadget-chain attack class does not apply. - If polymorphism is genuinely required, use a strict
PolymorphicTypeValidator(introduced in Jackson2.10) to allowlist only the exact base types and subtypes you expect, rather than allowing arbitrary classes. - Deserialize into specific, well-defined DTO classes — not
Objector open maps — so the type is fixed by your code, not by the incoming payload. - Disable features you do not need, such as accepting external entities in the XML dataformat, and keep
FAIL_ON_UNKNOWN_PROPERTIESbehavior deliberate. - Keep the whole Jackson family (
jackson-core,jackson-annotations, and the dataformat modules) on aligned, current versions via a BOM.
How to monitor jackson-databind with SCA and reachability
Jackson-databind is deeply transitive in Java builds, so a version-based scanner will report its CVEs in nearly every service you own. The question that actually determines risk is whether your application enables default typing and deserializes untrusted input through a reachable path. That is where reachability analysis earns its place.
Safeguard's software composition analysis resolves your Maven or Gradle dependency graph — including the jackson-databind version dragged in by frameworks you did not configure — and adds call-path reachability, so a deserialization CVE that your code can actually trigger is separated from one buried in an unused module. Griffin AI explains each finding in context — which gadget class, which configuration makes it exploitable, and the minimal safe change — and when a patched release exists, autonomous auto-fix opens a tested pull request to bump the version across the Jackson modules together.
Bring continuous, prioritized dependency analysis to your Java services — get started free or read the documentation.
Frequently Asked Questions
Which jackson-databind version should I use in 2026?
Use a current, supported release — the 2.15.x line or newer — and never run anything older than the 2.13.4.2/2.12.7.1 fixes for the denial-of-service CVEs. Because jackson-databind arrives transitively through so many frameworks, pin it explicitly (ideally via the Jackson BOM) so a stale copy does not slip in.
What actually makes jackson-databind vulnerable to RCE?
Enabling polymorphic default typing and then deserializing attacker-controlled JSON. That combination lets the payload specify which Java classes to instantiate, and a "gadget" class on your classpath can execute code as a side effect. If you never enable default typing, the entire family of gadget-chain CVEs does not apply to you.
Is it safe to enable default typing if I keep patching?
No — patching alone was historically a losing game, because each blocklisted gadget was followed by a newly discovered one. If you need polymorphism, use a strict PolymorphicTypeValidator to allowlist only the exact types you expect, rather than relying on the library to block dangerous classes for you.
Do the Jackson deserialization CVEs affect plain JSON, or only Java serialization?
They affect plain JSON. This is a common misconception. The gadget attacks work specifically through Jackson's JSON data binding when polymorphic typing is enabled, independent of Java's native serialization. Accepting "only JSON" does not make you immune.
How do I tell which jackson-databind CVEs matter for my service?
Use reachability-aware SCA. It checks whether your code enables the risky configuration and reaches a deserialization path with untrusted input, so you can focus on the CVEs that are genuinely exploitable in your service rather than every advisory that names the library.