CVE-2026-110879

Overview

jackson-databind is the general-purpose data-binding package of the FasterXML Jackson suite. It provides full data-binding (object serialization and deserialization) on top of the Jackson streaming parser/generator (jackson-core) and the Jackson annotations (jackson-annotations), and is one of the most widely used JSON libraries for Java.

A Remote Code Execution (RCE) vulnerability (CVE-2026-110879) has been identified in jackson-databind, which allows attackers to smuggle a class that the configured PolymorphicTypeValidator (PTV) would reject as a direct type id past that validator, by naming it as a generic type argument or as the element type of an array type id. The smuggled class is then instantiated and populated with attacker-controlled property values, so an attacker with a suitable gadget on the classpath can escalate this to arbitrary code execution. This is an incomplete-fix follow-up to CVE-2026-54512.

Per OWASP: The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid, allowing an attacker to control the type of object that is reconstructed and, with a suitable gadget, achieve arbitrary code execution.

This issue affects versions >=2.10.0 <2.18.12, >=2.19.0 <2.21.8, >=2.22.0 <2.22.4, >=3.0.0 <3.1.8, and >=3.2.0 <3.2.4 of jackson-databind.

Details

Module Info

• Product: jackson-databind
• Affected packages: jackson-databind
• Affected versions: >=2.10.0 <2.18.12, >=2.19.0 <2.21.8, >=2.22.0 <2.22.4, >=3.0.0 <3.1.8, >=3.2.0 <3.2.4
• GitHub repository: https://github.com/FasterXML/jackson-databind
• Published packages:
  • For 2.x: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind
  • For 3.x: https://central.sonatype.com/artifact/tools.jackson.core/jackson-databind
• Package manager: Maven
• Fixed in:
  • NES for Jackson 2.13.13, 2.14.10, and 2.15.11
  • Jackson Databind 2.18.12, 2.21.8, 2.22.4, 3.1.8, 3.2.4 (OSS)

Vulnerability Info

This critical severity vulnerability is found in jackson-databind. When polymorphic deserialization uses class-name type ids (via activateDefaultTyping(...), or a class- or minimal-class-based @JsonTypeInfo), the library is expected to instantiate only classes the configured PolymorphicTypeValidator approves. The fix for CVE-2026-54512 started validating the generic type arguments nested inside such a type id, but it did so incompletely, leaving three gaps:

• Arguments validated against the wrong type. DatabindContext._validateTypeParameter() checks each generic argument against the outer polymorphic base type instead of the argument's own declared binding, and hands validators arguments that never passed the subtype check those validators expect. Under the default DefaultBaseTypeLimitingValidator, a class that is rejected as a direct type id is accepted inside a generic subtype, for example Env<Gadget> where Env implements the polymorphic base type.
• allowIfBaseType() disables validation of arguments. When an allowIfBaseType(...) rule approves the outer type, StdTypeResolverBuilder.verifyBaseTypeValidity() substitutes LaissezFaireSubTypeValidator, so the configured validator no longer restricts the embedded arguments at all:

  final PolymorphicTypeValidator.Validity validity = ptv.validateBaseType(config, baseType);
  // If no subtypes are legal (that is, base type itself is invalid), indicate problem
  if (validity == PolymorphicTypeValidator.Validity.DENIED) {
      return reportInvalidBaseType(config, baseType, ptv);
  }
  // If there's indication that any and all subtypes are fine, replace validator itself:
  if (validity == PolymorphicTypeValidator.Validity.ALLOWED) {
      return LaissezFaireSubTypeValidator.instance; // type arguments no longer validated
  }

• Array element types are not validated. Once an array type id such as [Lpkg.Gadget; is approved (for example under allowIfBaseType(Serializable.class)), its element type is never validated. BasicPolymorphicTypeValidator.allowIfSubTypeIsArray() also auto-accepted arrays of any abstract or interface element type.

With class-name default typing and a rule that permits Map, a property declared as Map<String,String> accepts a type id such as java.util.HashMap<org.springframework.context.support.FileSystemXmlApplicationContext,String>. Map-key deserialization passes the attacker-controlled JSON property name to the selected class's single-String constructor; with Spring on the classpath and attacker-controlled XML loadable by the application, this invokes ProcessBuilder.start() under the application account, even though selecting the same class directly is rejected. Stock-JDK classes can be used in the same way to create or truncate files or to issue URL requests.

This vulnerability was introduced in 2019 with jackson-databind 2.10.

Mitigation

Only recent versions of Jackson are community-supported. The affected 2.13.x, 2.14.x, and 2.15.x lines are End-of-Life and will not receive public updates to address this issue. There is no publicly available fix for these lines; NES for Jackson is the remedy.

Users of the affected components should apply one of the following mitigations:

• Upgrade jackson-databind to a currently supported 2.x or 3.x release that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Adam Korczynski, Ada Logics (reporter)
• François Martin (finder)