jackson-databind CVE-2026-110879: Critical Fix Bypass, Patch Again

If you upgraded jackson-databind to 2.18.8, 2.21.4 or 3.1.4 in June to close CVE-2026-54512, you are still exposed. FasterXML's advisory for CVE-2026-110879, rated critical at CVSS 9.8, says those releases still let attacker-chosen classes through the polymorphic type validator. The real fixes are 2.18.12, 2.21.8, 2.22.4, 3.1.8 and 3.2.4, all on Maven Central since October 17.

jackson-databind is the JSON data-binding library inside most Java web stacks, usually pulled in as a transitive dependency of Spring, a client SDK or an internal framework. The flaw is a deserialization bug (turning attacker-supplied JSON into live Java objects) in the safety check meant to stop exactly that. The CVE record was published on October 28, eight days after the GitHub advisory. No in-the-wild exploitation has been reported and the CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of October 28. The advisory does point to a self-contained reproducer that works on the published jars as shipped, so assume the gap between disclosure and working attacks is short.

Why the June upgrade did not close it

Jackson can read a class name out of the JSON itself and build that class. The polymorphic type validator (PTV) is the allowlist that decides which names are acceptable. In June, CVE-2026-54512 showed the validator only looked at the outer container in a generic type such as a list or map, so a banned class could ride inside an approved one. The fix added checks on those inner type arguments.

According to the new advisory, the check was aimed at the wrong target. Each inner argument is compared with the outer base type instead of the generic binding the application declared, and validators get called with arguments that never passed the subtype test they assume. Two consequences follow. Under the stock default validator, a class Jackson rejects as a direct type ID is accepted when wrapped in a generic type. If the outer type is cleared by an allowIfBaseType(...) rule, Jackson swaps in a permissive validator that allows everything, so nothing restricts what sits inside. Array type IDs have the same hole: once the array is approved, the element type is not checked.

This is the third PTV bypass in jackson-databind we have tracked since June. CVE-2026-54513, which we covered in June, was an array allowlist bypass; CVE-2026-54512 was the generics case; this one finishes both. The pattern is worth naming. A type ID is a small recursive grammar (generics inside generics, arrays of generics), and an allowlist that checks one level at a time keeps leaving another level unchecked. Treat the validator as a speed bump, not the security boundary, and keep class-name typing away from untrusted input altogether.

Which jackson-databind versions fix CVE-2026-110879?

Upgrade to jackson-databind 2.18.12, 2.21.8 or 2.22.4 on the 2.x line (Maven group com.fasterxml.jackson.core), or 3.1.8 or 3.2.4 on the 3.x line (group tools.jackson.core). Every release from 2.10.0 up to those builds is affected. Releases before 2.10.0 do not have the validator and are outside this CVE.

The June column matters for one reason: software composition analysis (SCA) tools that marked CVE-2026-54512 resolved at 2.18.8, 2.21.4 or 3.1.4 showed green for four months. Those same builds now carry a new critical CVE, so expect fresh alerts on services nobody has touched since summer.

Is your application on the vulnerable path?

An attacker has to feed JSON carrying a type identifier into code that looks classes up by name. The advisory lists several ways that happens:

• Annotation-based class-name typing on Jackson 3.x. A field or class annotated with @JsonTypeInfo(use = Id.CLASS) and read by a default 3.x JsonMapper is affected with no custom validator involved.

• Default typing on 2.x or 3.x. Any mapper configured with activateDefaultTyping (or the older enableDefaultTyping) is in scope, including ones restricted with allowIfBaseType(...).

• Libraries that turn default typing on for you. The advisory names two: the older Jackson 2 support module in Spring Security, and the RedisSerializer.json() serializer in Spring Data Redis 4.0.7.

The Redis case deserves a second look. With a JSON serializer that resolves class names, whoever can write a session or cache entry chooses which classes your application builds when it reads that entry back. A Redis instance reachable from other tenants or containers, or protected only by a shared password, is part of this attack surface even though the JSON never comes through your public API.

What an attacker can do depends on the classes on your classpath. With only the stock JDK available, the advisory's examples stop at writing or emptying files and forcing the server to fetch URLs. They go further, to running commands as the service account, when Spring is on the classpath and the app can be steered into loading XML the attacker controls. Plain data binding to fixed types, with no class names in the payload, is not on the vulnerable path.

find / -xdev -name 'jackson-databind-*.jar' 2>/dev/null
for f in $(find / -xdev \( -name '*.jar' -o -name '*.war' \) -size +5M 2>/dev/null); do
  unzip -l "$f" 2>/dev/null | grep -q 'jackson-databind' && echo "$f"
done
grep -rnE 'activateDefaultTyping|enableDefaultTyping|Id\.CLASS|allowIfBaseType|RedisSerializer\.json|GenericJackson2JsonRedisSerializer' src/

The first command finds standalone jars on a host. The loop catches fat jars and WAR files that bundle their own copy, which is the copy a package scan of the host misses (the same problem we described for bundled Brotli decoders last week). The grep runs against source trees and flags the settings that put a mapper on the vulnerable path. A hit is a place to review, not proof of exposure.

Stopgaps if you cannot ship a new build today

FasterXML lists four interim measures. Keep class names out of anything an outsider can send. Replace broad base-type rules with short lists of concrete classes. Make sure no attacker can plant entries in your caches or session stores. And drop libraries you do not use, since each one adds classes an attacker can abuse. The first one holds up best. Switching Id.CLASS to logical type names (Id.NAME with registered subtypes) removes the attacker's ability to name a class at all, and it survives the next validator bypass too.

For the Redis path, lock down who can write to the instance: require authentication per application, keep it off shared networks, and check that no lower-trust service shares the keyspace.

Rebuild on 2.18.12 or later, then check the jar that ships

Bump jackson-databind in your dependency management (Maven dependencyManagement, a Gradle platform or constraint, or the Spring Boot jackson-bom.version property), rebuild, and confirm the version inside the artifact you deploy, not just in the build file. Transitive pins and shaded copies are why June's fixes took weeks to land in many fleets. Distribution-packaged Jackson builds follow their own release schedule, so check your vendor's tracker before assuming an OS update covers the Java services on a host.

Then audit the configuration, because the version bump only closes the bypass that is known today. Any mapper that reads class names from untrusted JSON is relying on a validator that has been bypassed three times since June.