CVE-2019-14379: Jackson-databind deserialization via jdk....

Jackson-databind's polymorphic deserialization feature has produced one of the longest-running vulnerability sagas in the Java ecosystem, and CVE-2019-14379 is a representative entry in that series. The flaw affects FasterXML's jackson-databind library and allows an attacker who can control JSON input to a vulnerable application to trigger remote code execution or other unsafe side effects, provided the application has enabled default (polymorphic) typing. This particular CVE adds jdk.nashorn.internal.objects.NativeString — a class from the JDK's built-in Nashorn JavaScript engine — to the list of "gadget" classes that can be abused during deserialization when an attacker supplies a crafted type identifier alongside malicious JSON.

For teams that embed jackson-databind deep inside internal services, message queues, or REST APIs, this CVE is a useful case study in why transitive dependency hygiene and default-typing configuration matter as much as patching itself.

What the vulnerability actually is

Jackson-databind supports "polymorphic type handling," a feature that lets the library serialize and deserialize Java objects without knowing their concrete class ahead of time. When polymorphic typing is enabled — either globally via ObjectMapper.enableDefaultTyping() or selectively via @JsonTypeInfo annotations — the JSON payload itself can specify which Java class to instantiate during deserialization.

This design becomes dangerous when the JSON is untrusted. An attacker can specify the name of a class that isn't meant to be deserialized directly but that has side effects in its constructor, static initializer, or accessor methods when instantiated — a "gadget." Chaining together the right gadget with the right setter/getter behavior can lead to outcomes ranging from server-side request forgery and denial of service to full remote code execution, depending on what the gadget class does.

Because jackson-databind cannot feasibly enumerate every dangerous class in the JVM ecosystem, the project has historically defended against this by maintaining a deny-list (BAD_ATTR_NAMES / blocked class list) of known-dangerous gadget classes, updating it reactively each time a security researcher finds a new one. jdk.nashorn.internal.objects.NativeString, addressed in CVE-2019-14379, is one of dozens of classes added to that list over multiple releases in 2018 and 2019. Nashorn is the JavaScript engine shipped inside the JDK itself, and NativeString is one of its internal object wrapper types — an unusual gadget in that it comes from the JDK, not from a third-party library on the classpath, which meant even minimal dependency trees could be affected if the JVM's own Nashorn classes were present.

Affected versions and components

• Component: com.fasterxml.jackson.core:jackson-databind (and by extension anything bundling it, such as Spring Boot's default JSON stack, many REST frameworks, and message-broker serializers that use Jackson under the hood).
• Affected versions: jackson-databind releases prior to 2.9.10.
• Fixed version: 2.9.10, which added jdk.nashorn.internal.objects.NativeString to the blocked-classes list used during polymorphic deserialization.
• Precondition for exploitation: The application must have polymorphic/default typing enabled (enableDefaultTyping(), @JsonTypeInfo with broad visibility, or equivalent configuration) and must deserialize JSON from an untrusted source. Applications that only ever deserialize into concrete, statically-typed classes without polymorphic type resolution are not exploitable through this particular gadget.
• Runtime dependency: Because the gadget class lives inside Nashorn, exploitability also depends on the Nashorn engine being present and accessible on the classpath at runtime — true for most JDK 8–14 deployments, since Nashorn shipped as part of the standard library during that window before its later removal from the JDK.

CVSS, EPSS, and KEV context

CVE-2019-14379 is tracked by NVD as a jackson-databind deserialization issue with network attack vector and no privileges required, consistent with the broader family of jackson-databind polymorphic-typing CVEs from this period, most of which were scored in the medium-to-high range rather than critical — reflecting that exploitation requires the non-default precondition of polymorphic typing being enabled, not just the library being present.

This CVE has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, and we are not aware of confirmed widespread in-the-wild exploitation specific to this CVE identifier. That said, jackson-databind gadget chains as a category have been actively used in real-world attack tooling and red-team frameworks for years, including in some ransomware and post-exploitation toolkits, precisely because default typing shows up more often in production code than developers expect — frequently introduced transitively through frameworks or copied configuration rather than a deliberate, reviewed decision. Treat the absence of a KEV listing as a statement about this specific CVE ID, not about the risk class it belongs to.

Timeline

• Root cause introduced: The underlying architectural risk — polymorphic deserialization trusting attacker-supplied type identifiers — predates this CVE by years and is common to the entire "jackson-databind gadget" CVE family that began surfacing publicly around 2017.
• Blocklist gap discovered: Security researchers systematically fuzzing the JVM classpath for usable deserialization gadgets identified jdk.nashorn.internal.objects.NativeString as bypassing jackson-databind's then-current blocked-classes list.
• Fix released: FasterXML shipped jackson-databind 2.9.10, extending the deny-list to cover the Nashorn gadget alongside several other classes patched around the same release line.
• Disclosure: CVE-2019-14379 was published to track this specific fix, as part of a wave of related CVEs (covering other gadget classes) disclosed in the same period — a pattern typical of this deny-list-driven remediation approach, where each newly discovered gadget gets its own CVE even though the underlying design flaw is shared across all of them.

Because the fix approach is reactive (block newly-found classes one at a time), later jackson-databind releases (2.10 and beyond) shifted toward requiring explicit allow-listing of classes eligible for polymorphic deserialization, which is the more durable mitigation.

Remediation steps

1. Upgrade jackson-databind. Move to 2.9.10 or later, and ideally to a current 2.x release line, which folds in the cumulative deny-list fixes plus the stronger allow-list-based PolymorphicTypeValidator mechanism introduced in 2.10+.
2. Audit for default typing. Search your codebase and any inherited framework configuration for enableDefaultTyping(), activateDefaultTyping(), or broad @JsonTypeInfo usage. If it's not a deliberate, reviewed requirement, disable it.
3. Adopt allow-listing over deny-listing. If polymorphic typing is genuinely required, use BasicPolymorphicTypeValidator (or a custom PolymorphicTypeValidator) to explicitly permit only the base types and packages your application legitimately needs to deserialize, rather than relying on jackson-databind's built-in blocklist as your only defense.
4. Check transitive exposure. jackson-databind is frequently pulled in transitively by web frameworks, RPC layers, and message-queue clients. Confirm the resolved version in your dependency tree (mvn dependency:tree / gradle dependencies), not just the version declared in your direct pom.xml or build.gradle.
5. Validate and constrain input sources. Never deserialize JSON from untrusted or externally-reachable sources into polymorphic types without strict schema and type constraints, regardless of library version — defense in depth matters given the history of new gadgets being found in already-patched versions.
6. Watch for JDK-level exposure. Because this gadget lived inside the JDK's own Nashorn engine rather than a third-party jar, confirm whether your JVM version ships Nashorn and whether it's reachable, particularly on older JDK 8–14 deployments still in production.

How Safeguard Helps

CVE-2019-14379 illustrates a recurring theme in software supply chain risk: the vulnerable code often isn't a library you chose directly, and the exploitability condition (default typing enabled) isn't visible from a version number alone. Safeguard is built to close exactly that visibility gap.

• Full dependency graph resolution surfaces jackson-databind wherever it appears — direct or transitive — across your services, so you're not relying on manually walking build files to find every exposed component.
• SBOM-driven vulnerability matching continuously cross-references your actual deployed component versions against CVE feeds, flagging affected jackson-databind versions the moment new advisories land, rather than waiting for a periodic audit cycle.
• Prioritization beyond raw CVSS helps teams triage findings like this one, where exploitability hinges on configuration (default typing) rather than mere presence of the library — reducing alert fatigue from CVEs that don't apply to how you actually use a dependency.
• Policy gates in CI/CD let you block builds that introduce known-vulnerable jackson-databind versions or reintroduce risky deserialization configuration, catching regressions before they reach production.
• Historical and ongoing monitoring for the broader jackson-databind gadget-chain CVE family means you're not just fixing this one CVE — you're positioned to react quickly the next time a new gadget class is discovered, which history suggests is a matter of when, not if.

Deserialization vulnerabilities like this one rarely announce themselves loudly; they wait in configuration choices and transitive dependencies until someone finds the right gadget. Continuous, graph-aware visibility is what turns that into a manageable, prioritized fix rather than a fire drill.