Jackson Versions, EOL Dates, and Latest Releases (October 2026)

The short answer:

• Is Jackson 2 end of life? No. Jackson 2.x is maintained alongside Jackson 3.x. The 2.21 LTS branch is supported until at least January 31, 2028, and 2.23 is in development. Individual 2.x branches do reach end of life, and the next one is 2.18 at the end of 2026.
• Latest Jackson versions: Jackson 2.22.4 (October 17, 2026) and Jackson 3.2.4 (October 18, 2026). The two LTS lines are at 2.21.8 and 3.1.8, and 2.18 is at 2.18.12, all released October 17, 2026.
• Next end-of-life date: Jackson 2.18, the oldest supported branch, is planned to close at the end of 2026. After that, the oldest supported 2.x line is 2.21.
• Recommended for production: Jackson 3.1 (LTS) if you are on Java 17+ or Spring Boot 4, or Jackson 2.21 (LTS, open until at least January 31, 2028) if you are staying on 2.x.
• Branches already end-of-life: 2.17 and every older 2.x branch, plus 2.19, 2.20, and 3.0.
• Newest critical CVE: CVE-2026-110879 (CVSS 9.8), a polymorphic type validation bypass in jackson-databind, published by HeroDevs as the CVE Numbering Authority for Jackson's security advisories. Fixed in 2.18.12, 2.21.8, 2.22.4, 3.1.8, and 3.2.4. Every closed branch from 2.10 onward is affected and gets no upstream fix. Details below.

FasterXML Jackson is the JSON library of the JVM. It is the default JSON mapper in Spring Boot, and Maven Central data indexed by ecosyste.ms shows jackson-databind with more than 23,000 dependent packages and more than 244,000 dependent repositories. If you run Java, Kotlin, or Scala services, you almost certainly ship Jackson, often several copies of it pulled in transitively.

That reach is why Jackson's lifecycle matters more than most libraries'. A branch closing upstream does not remove it from your dependency tree. It just means the next deserialization CVE lands without a patch for the version you run. 2026 has been a heavy year: more than two dozen Jackson CVEs disclosed since June, several of them rated High or Critical, and the closed branches got none of the fixes. HeroDevs sits on both sides of that problem: we are the CVE Numbering Authority that publishes Jackson's CVEs, and through Never-Ending Support we patch the branches upstream no longer does.

This page is the definitive reference for Jackson's release and support lifecycle: every branch's release date, end-of-life date, and latest patch, the CVEs that matter, which Jackson version each Spring Boot release uses, and the options for teams stuck on a closed branch. It is updated as new versions ship.

Is Jackson 2 End of Life?

No. Jackson 2 is not end of life. The Jackson project maintains 2.x and 3.x as parallel lines, each with its own LTS branches. Jackson 2.21 is an LTS branch committed to receive patches until at least January 31, 2028, 2.22 is the current 2.x release branch, and 2.23 is in development.

What does reach end of life is individual 2.x minor branches. Every 2.x branch from 2.17 back, plus 2.19 and 2.20, is closed and gets no new patches, including for the 9.8 CVE-2026-110879. Jackson 2.18 is the next to close, at the end of 2026. So the useful question is not "is Jackson 2 EOL" but "is my 2.x branch still open," which the quick reference table answers.

The confusion is understandable. Jackson 3.0 shipped in October 2025 with a new tools.jackson groupId, and Spring Boot 4 moved to it, so it is easy to assume 2.x was retired. It was not: Spring Boot 4 still manages a Jackson 2 BOM alongside Jackson 3, and a large share of the libraries in a typical JVM dependency tree are still built against Jackson 2. Nothing published by the Jackson project sets an end date for the 2.x line as a whole.

How Jackson's Support Policy Works

Jackson does not use the words "active support" or "security support." The project describes every minor version branch (2.18, 2.21, 3.1, and so on) as either open or closed:

• Open: the branch can get new patch releases. Fixes, including security fixes, are backported to it.
• Closed: no new patch releases are planned. The Jackson wiki notes that micro-patches of individual components are possible "in some rare cases," but you should not plan around them. A closed branch is end-of-life.

Since 2025, Jackson has had a formal Long-Term Support (LTS) designation, defined in JSTEP-13. The rules:

• A branch is designated LTS (or not) when its .0 version ships. Roughly every third minor version becomes LTS.
• An LTS branch stays open for at least two years after its .0 release. Each LTS gets its own committed minimum date.
• Only LTS branches and the most recent release branch stay open. When a new .0 ships, the previous non-LTS branch closes, usually after one final patch.
• Jackson 2.x and 3.x have separate LTS tracks. Fixes are merged up from 2.x to 3.x.

The current LTS branches are 2.18, 2.21, and 3.1. The non-LTS branches currently open are 2.22 and 3.2, the latest release branches for each major version. Branches 2.23 and 3.3 started development in June 2026 and will not be LTS.

Before JSTEP-13, Jackson kept the last few minor versions open "train style" and closed the oldest whenever a new .0 shipped. That is why closure dates for 2.17 and earlier line up with other branches' .0 releases rather than any calendar date. The Jackson README is explicit that the community supports open branches only, and that commercial support exists for closed ones.

Jackson follows Apache-style versioning. Major versions (1.x to 2.x, 2.x to 3.x) use different Java packages and Maven *groupId*s, so different major versions can sit on the same classpath. Minor versions can deprecate and occasionally remove deprecated methods. Patch releases are meant to be drop-in replacements.

Complete Jackson Version Timeline

Dates come from the Jackson Releases wiki, per-branch release pages, and Maven Central publish timestamps. For 2.17 and earlier, the EOL date is the day the branch was closed by a newer .0 release. The 2.12 closure date is listed inconsistently in the Jackson wiki; its final full release was 2.12.7.

Latest Jackson Release per Branch

Current as of October 28, 2026. All five open branches shipped on October 17-18, 2026, primarily to fix CVE-2026-110879 and a set of binary dataformat parser CVEs. These are the minimum versions to be running.

Jackson ships patches as a coordinated set: jackson-core, jackson-databind, and the dataformat, datatype, and module artifacts all share the patch number, and jackson-bom pins them together. Since 2.20, jackson-annotations is the exception: it carries only a major.minor version (for example, 2.21), and Jackson 3.x continues to use the 2.x annotations artifact.

The easiest way to stay on a coherent set is to import the BOM rather than versioning artifacts individually:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson</groupId>
      <artifactId>jackson-bom</artifactId>
      <version>2.21.8</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

For Jackson 3, the BOM coordinates are tools.jackson:jackson-bom. To see what you actually resolve today, run mvn dependency:tree -Dincludes=com.fasterxml.jackson.core or ./gradlew dependencyInsight --dependency jackson-databind. Mixed patch versions across Jackson artifacts are a common source of both scanner noise and runtime errors.

Which Jackson Version Does Spring Boot Use?

Most teams do not choose a Jackson version. Spring Boot's dependency management chooses it for them, through the jackson-bom.version property. Here is what each Spring Boot line manages, checked against the spring-boot-dependencies POMs on Maven Central:

Two things stand out.

First, a Spring Boot version pins a Jackson patch, and that patch can fall far behind its own branch. Spring Boot 3.4.13 manages Jackson 2.18.5. The 2.18 branch is still open, but 2.18.5 predates the fixes for CVE-2026-54512, CVE-2026-54513, CVE-2026-110879, and roughly a dozen others. "My Jackson branch is supported" and "my Jackson is patched" are different statements.

Second, every Spring Boot 2.x and 3.0 through 3.3 application is on a closed Jackson branch by default. Overriding jackson-bom.version to a newer branch is possible, but Spring Boot only tests against the version it manages, and jumping several Jackson minors under an old Spring Boot is its own compatibility project. For the Spring Boot side of the lifecycle, see our Spring Boot versions and EOL dates reference.

Jackson CVEs in 2026: What Is Fixed Where

Jackson's CVE history has two distinct eras. From 2017 to 2020, jackson-databind 2.9.x accumulated dozens of CVEs for polymorphic deserialization "gadget" classes, each fixed by adding classes to a blocklist. Jackson 2.10 replaced that model with PolymorphicTypeValidator (PTV), an allowlist-style safety mechanism, and the CVE flow slowed dramatically for several years.

2026 broke that quiet. Beginning in June, a sustained research effort against jackson-databind, jackson-core, and the binary dataformat modules produced more than two dozen CVEs, including two separate bypasses of PolymorphicTypeValidator itself. HeroDevs works with the Jackson maintainers as the CVE Numbering Authority (CNA) for Jackson's security advisories. When the maintainers publish a GitHub security advisory for jackson-core, jackson-databind, or the dataformat modules, HeroDevs assigns the CVE ID and publishes the record that cve.org, NVD, and your scanner all consume. Since August 2026, HeroDevs has published nearly every Jackson CVE, including the critical CVE-2026-110879 and CVE-2026-104016 in the Protobuf parser. (Before August, Jackson advisories went through GitHub's CNA.)

That role means HeroDevs sees the full Jackson vulnerability stream, with severity, affected ranges, and fix commits, from the same source as the maintainers. It is also why we can say with confidence which closed branches each CVE reaches. The ones that matter most:

For the technical breakdowns, see our deep-dives on CVE-2026-54512/54513, CVE-2026-59888, CVE-2025-52999, and the related Spring Framework JMS Jackson deserialization flaw (CVE-2026-41855).

Is your application exposed to the Jackson polymorphic typing CVEs?

The two PTV bypasses (CVE-2026-110879 and CVE-2026-54512/54513) matter when your application deserializes untrusted input into types that use polymorphic handling: @JsonTypeInfo with class-name type IDs (Id.CLASS or Id.MINIMAL_CLASS), or default typing enabled through activateDefaultTyping() or the older enableDefaultTyping(). If you rely on PolymorphicTypeValidator to restrict which classes an attacker can name, these CVEs are bypasses of exactly that control. Name-based type IDs (Id.NAME) are not the attack path for these two, though CVE-2026-91776 targets Id.NAME with a defaultImpl fallback.

The denial-of-service CVEs have a wider blast radius. Any endpoint that parses attacker-controlled JSON, Smile, CBOR, Avro, or Protobuf is in scope, regardless of how you configure typing.

Versions Reaching EOL Next: What to Watch

Jackson 2.18 End of Life: End of 2026

Jackson 2.18 was the first 2.x branch designated LTS, with a committed minimum of two years from its September 26, 2024 release. The 2.18 release page states the branch "is planned to remain open until end of 2026." After that, new Jackson CVEs will be fixed in 2.21, 2.22, and 3.x only.

2.18 is a large population. It is the Jackson line behind every Spring Boot 3.4 application, and many teams that pinned Jackson independently landed on it because it was the only LTS available until January 2026. 2.18.12, released October 17, 2026, fixes CVE-2026-110879 and every other CVE in the table above that affects the branch, so the immediate action for 2.18 users is to get to 2.18.12. The decision after that is what you run in January 2027. The upgrade from 2.18 to 2.21 stays within 2.x and is typically modest; see Options for EOL Jackson Versions for what to test.

Jackson 2.22 and 3.2: When the Next Minor Ships

Neither 2.22 nor 3.2 is LTS. Under JSTEP-13, each closes when its successor's .0 release ships (2.23.0 and 3.3.0, both in development since June 2026), usually after one final patch. Jackson has not published dates for those releases. If you want a branch with a known support horizon, use 2.21 or 3.1 instead.

Jackson 2.21 and 3.1: Early 2028

Jackson 2.21 is committed to stay open until at least January 31, 2028. Jackson 3.1 is committed to at least two years from its February 23, 2026 release, so no earlier than February 2028. These are the safest targets for teams planning a single upgrade that should hold for more than a year.

End-of-Life Jackson Versions in Detail

Jackson 3.0 End of Life

• EOL Date: February 23, 2026 (closed when 3.1.0 shipped)
• Last Release: 3.0.4 (January 21, 2026)

Jackson 3.0 was the first new major version in more than a decade, and it was never LTS. It closed less than five months after GA. That caught Spring Boot 4.0 early adopters, since Spring Boot 4.0.0 shipped managing Jackson 3.0.2; later Spring Boot 4.0.x patches moved to 3.1. Applications that pinned 3.0 explicitly are on a closed branch, with 14 known jackson-databind CVEs against 3.0.4 plus CVE-2026-110879. Moving from 3.0 to 3.1 is a minor-version upgrade, but 3.1 deliberately front-loaded a last set of default and configuration changes, so read the 3.1 release notes before bumping.

Jackson 2.19 and 2.20 End of Life

• 2.19 EOL: October 29, 2025, with final release 2.19.4
• 2.20 EOL: January 19, 2026, with final release 2.20.2

Neither was LTS, and both closed within months. 2.19 is the Jackson line Spring Boot 3.5.0 shipped with; 2.20 is the 2.x line Spring Boot 4.0.0 managed alongside Jackson 3.0. Both are affected by CVE-2026-110879, CVE-2026-54512/54513, and the rest of the 2026 jackson-databind set. The fix is to move to 2.21, which is a short hop.

Jackson 2.16 and 2.17 End of Life

• 2.16 EOL: April 24, 2025 (closed when 2.19.0 shipped), final release 2.16.2 (March 9, 2024)
• 2.17 EOL: August 28, 2025 (closed when 2.20.0 shipped), final release 2.17.3 (November 1, 2024)

These are the last branches from the pre-LTS "train" model. 2.17 is what Spring Boot 3.3 manages. Note that both branches went more than a year without a release before they were formally closed, so their effective patch window ended well before the official closure date.

Jackson 2.15 End of Life

• EOL Date: September 26, 2024 (closed when 2.18.0 shipped)
• Last Release: 2.15.4 (February 15, 2024)

Jackson 2.15 introduced StreamReadConstraints, the processing limits that underpin most of Jackson's denial-of-service defenses: a 1,000-character maximum for number tokens, a 1,000-level maximum nesting depth, and a maximum string value length (5 million units in 2.15.0, raised to 20 million in 2.15.1). Spring Boot 3.1 and 3.2 manage 2.15.x, which makes it one of the most widely deployed closed branches. It is affected by every high-severity jackson-databind CVE disclosed in 2026, plus CVE-2026-59888, which only reaches back to 2.15.

Jackson 2.14 End of Life

• EOL Date: November 15, 2023 (closed when 2.16.0 shipped)
• Last Release: 2.14.3 (May 5, 2023)

Jackson 2.14 raised the jackson-core baseline to Java 8 and the minimum Android SDK to 26. It is the Jackson line behind Spring Boot 3.0. Because it predates the 2.15 processing limits, 2.14 is also exposed to CVE-2025-52999, the deep-nesting stack overflow in jackson-core.

Jackson 2.13 End of Life

• EOL Date: November 15, 2023 (closed when 2.16.0 shipped)
• Last Release: 2.13.5 (January 23, 2023)

2.13 was kept open longer than usual because it was the last branch where jackson-core supports Java 6 and the last to support Android SDK 21+. It is the Jackson line managed by Spring Boot 2.6 and 2.7, so it remains everywhere that Spring Boot 2.x does. On top of the 2026 jackson-databind set, 2.13 is exposed to CVE-2026-50193 and CVE-2025-52999.

Jackson 2.12 and Older

Jackson 2.12 (final release 2.12.7, plus a jackson-databind 2.12.7.2 micro-patch in May 2024) added java.lang.Record support. 2.10 and 2.11 closed in 2021 and 2022. 2.9, the line that defined the gadget-CVE era, closed on January 6, 2021 with the jackson-databind 2.9.10.8 micro-patch. Everything from 2.10 forward is inside the CVE-2026-110879 affected range.

Jackson 1.x (org.codehaus.jackson, final release 1.9.13) has been unsupported for over a decade, and the Jackson project notes it has no working mechanism to publish new 1.x releases at all. It still turns up as a transitive dependency of old Hadoop-era and JAX-RS libraries, and jackson-mapper-asl 1.9.13 carries known XXE vulnerabilities, including CVE-2019-10172.

What Happens After a Jackson Branch Reaches End of Life

Security fixes stop. The 2026 CVE wave is the proof. The Jackson maintainers fixed CVE-2026-110879 on five open branches in a single day. The eleven closed branches inside the affected range (2.10 through 2.17, 2.19, 2.20, and 3.0) got nothing, and the release pages for closed branches like 2.15 say plainly "no plans to release."

Framework and runtime compatibility drifts. Jackson is rarely upgraded on its own. Its version is coupled to Spring Boot, Quarkus, Micronaut, Dropwizard, Kafka clients, AWS SDKs, and Elasticsearch clients, among others. Staying on a closed branch usually means you are also pinned on an older framework, and the newer framework you would upgrade to expects a newer Jackson. Jackson 3.x adds a hard Java 17 floor.

Scanners and auditors flag it. SCA tools (Snyk, Dependabot, Sonatype, Mend, Black Duck, Trivy, Grype) match CVE ranges against jackson-databind and jackson-core coordinates, and a closed branch accumulates findings with no fix version on its own line. Under PCI DSS 4.0 Requirement 6.3.3, critical vulnerabilities need a fix within one month of release, which a 9.8 CVE on a closed branch cannot meet without a patched build. SOC 2, HIPAA, FedRAMP, NIS2, and DORA all expect known vulnerabilities in third-party components to be remediated or formally risk-accepted. The EU Cyber Resilience Act's vulnerability-reporting obligations for manufacturers took effect in September 2026, with full obligations applying from December 2027, and a JSON parser with open CVEs is exactly the kind of component those obligations cover.

Is My Jackson Version Supported?

Options for EOL Jackson Versions

1. Upgrade Within Jackson 2.x

For most teams on a closed 2.x branch, the target is 2.21 LTS. Within 2.x, minor upgrades are meant to be source compatible, and for many codebases the change is a BOM version bump. The effort lives in behavior changes, and how much you hit depends on how far you jump:

• Crossing 2.15 turns on StreamReadConstraints. Services that legitimately parse very large strings, very long numbers, or very deep documents will start throwing until you raise the limits on the JsonFactory.
• Crossing 2.18 brings the rewritten property introspection. Custom serializers, @JsonCreator usage, and edge cases around renamed or ignored properties are where regressions show up.
• Crossing 2.20 changes jackson-annotations versioning to major.minor, which breaks build scripts that set one patch version for every Jackson artifact.
• Framework coupling is usually the real constraint. If you are on Spring Boot 2.7 (Jackson 2.13) or 3.2 (Jackson 2.15), overriding to 2.21 runs Jackson outside what Spring Boot tested, and the clean path is a Spring Boot upgrade that brings Jackson with it.

A contract test suite that round-trips your real payloads through ObjectMapper before and after the upgrade catches most of this. Without one, a Jackson upgrade across hundreds of services is the risk, not the version bump.

2. Migrate From Jackson 2 to Jackson 3.x

Jackson 3 is a real migration, not a version bump:

• New Maven groupId and Java packages: com.fasterxml.jackson becomes tools.jackson (annotations stay in com.fasterxml.jackson.annotation).
• Java 17 minimum.
• ObjectMapper and related core objects are immutable and built through builders such as JsonMapper.builder().
• Exceptions are unchecked: JacksonException extends RuntimeException.
• Java 8 date/time support is built into jackson-databind, and WRITE_DATES_AS_TIMESTAMPS now defaults to false, so dates serialize as ISO-8601 strings unless you change it.

JsonMapper.builderWithJackson2Defaults() exists to soften the default changes during a migration. Because 2.x and 3.x use different packages, they can coexist on one classpath, which lets you migrate module by module. For Spring applications, Jackson 3 arrives with Spring Boot 4, so this migration usually rides along with a Spring Boot 3 to 4 upgrade. Our Spring Boot 3.5 migration sizing covers that effort.

3. Use HeroDevs Never-Ending Support (NES) for Jackson

For teams that cannot upgrade on the upstream timeline, HeroDevs NES for Jackson provides patched, drop-in builds of the closed 2.13.x, 2.14.x, and 2.15.x branches. Coverage starts the day a branch closes upstream, and it spans the artifacts services actually pull in: jackson-core, jackson-databind, jackson-annotations, the BOM, the XML, YAML, CSV, CBOR, Smile, Avro, and Protobuf dataformats, the JSR-310 and JDK 8 datatypes, and the Kotlin, Scala, Afterburner, and Blackbird modules.

The October 2026 fixes show what that means in practice. NES shipped CVE-2026-110879 and CVE-2026-59889 fixes for all three lines on October 23, 2026 (NES 2.13.13, 2.14.10, and 2.15.11), six days after upstream fixed its open branches, on branches the Jackson project will not patch. That was five days before the CVE-2026-110879 record itself went live on cve.org on October 28. Earlier 2026 NES releases covered CVE-2026-54512 through CVE-2026-54517, CVE-2026-59888, CVE-2026-91776, CVE-2026-91777, and the rest of the 2026 jackson-databind set. The relationship with the Jackson project runs deeper than patching forks. Jackson is hosted by the Commonhaus Foundation, and HeroDevs is a founding member of the Commonhaus Open Source Sustainability Initiative, which funds the long-term stewardship of Commonhaus projects. HeroDevs is also the CNA that publishes Jackson's CVEs. NES for Jackson is built by the same team that handles Jackson's CVE records, so a fix for a closed branch is not reverse-engineered from a public advisory after the fact.

For a Spring Boot application, adopting NES is one property change plus the NES registry:

<properties>
  <jackson-bom.version>2.15.4-jackson-bom-2.15.11</jackson-bom.version>
</properties>

No application code changes, and each build ships with VEX (Vulnerability Exploitability eXchange) statements so remediated CVEs come off your scanner reports. Setup details are in the NES for Jackson documentation.

Frequently Asked Questions

Is Jackson 2 end of life?

No. Jackson 2 is still maintained alongside Jackson 3. Jackson 2.21 is an LTS branch supported until at least January 31, 2028, 2.22 is the current 2.x release branch, and 2.23 is in development. Individual 2.x branches reach end of life (2.17 and older, 2.19, and 2.20 are closed, and 2.18 closes at the end of 2026), but the 2.x line as a whole has no announced end date.

What is the latest Jackson version?

As of October 28, 2026, the latest Jackson releases are 2.22.4 (October 17, 2026) for Jackson 2.x and 3.2.4 (October 18, 2026) for Jackson 3.x. The LTS branches are at 2.21.8, 3.1.8, and 2.18.12. The Jackson Releases wiki lists current patches for every open branch.

Does Jackson have LTS versions?

Yes. Since 2025, Jackson designates some minor versions as Long-Term Support, with a minimum of two years of patches from the .0 release. The current LTS branches are 2.18 (open until end of 2026), 2.21 (open until at least January 31, 2028), and 3.1 (open until at least February 2028).

When does Jackson 2.18 reach end of life?

Jackson 2.18 is planned to remain open until the end of 2026. After that, new CVEs will not be fixed on 2.18. Teams on 2.18 should update to 2.18.12 now and plan an upgrade to 2.21 LTS or Jackson 3.1 before January 2027.

Is Jackson 2.15 still supported?

No. Jackson 2.15 closed on September 26, 2024, when 2.18.0 was released. Its last release was 2.15.4 (February 15, 2024). It is affected by CVE-2026-110879 (CVSS 9.8) and the rest of the 2026 jackson-databind CVEs, with no upstream fix. Patched 2.15.x builds are available through HeroDevs NES for Jackson.

Which Jackson version does Spring Boot use?

Spring Boot 2.6 and 2.7 manage Jackson 2.13. Spring Boot 3.0 manages 2.14, 3.1 and 3.2 manage 2.15, 3.3 manages 2.17, 3.4 manages 2.18, and 3.5 started on 2.19 and moved to 2.21 in later patches. Spring Boot 4.0 and 4.1 manage Jackson 3.x (3.1 in current patches) alongside a 2.x BOM for libraries that still need it.

What is the difference between Jackson 2 and Jackson 3?

Jackson 3 uses the tools.jackson Maven groupId and Java packages (Jackson 2 uses com.fasterxml.jackson), requires Java 17, makes ObjectMapper immutable and builder-constructed, switches to unchecked exceptions, builds in Java 8 date/time support, and changes several defaults, including serializing dates as ISO-8601 strings. Jackson 3 keeps using the 2.x jackson-annotations artifact.

Can Jackson 2 and Jackson 3 run in the same application?

Yes. Because Jackson 3 uses different Java packages and Maven groupIds, both can be on the classpath at once. Spring Boot 4 does this by default, managing a Jackson 3 BOM and a Jackson 2 BOM side by side.

Is Jackson 1.x still supported?

No. Jackson 1.x (org.codehaus.jackson) has been unsupported for more than a decade, and its final release was 1.9.13. The Jackson project has no working way to publish new 1.x releases. Applications still pulling in jackson-mapper-asl should migrate to Jackson 2.21+ or 3.1+.

What is CVE-2026-110879?

CVE-2026-110879 (CVSS 9.8) is a bypass of Jackson's PolymorphicTypeValidator: jackson-databind validated the outer class of a class-name type ID but accepted attacker-chosen classes inside generic type arguments and array element types. It is an incomplete fix for CVE-2026-54512. It affects jackson-databind 2.10.0 and later, and it is fixed in 2.18.12, 2.21.8, 2.22.4, 3.1.8, and 3.2.4. Closed branches, including 2.13 through 2.17, 2.19, 2.20, and 3.0, have no upstream fix.

Who publishes Jackson CVEs?

HeroDevs is the CVE Numbering Authority (CNA) for Jackson's security advisories. When the Jackson maintainers publish a GitHub security advisory, HeroDevs assigns the CVE ID and publishes the record to cve.org, which feeds NVD and vulnerability scanners. Since August 2026, HeroDevs has published nearly every Jackson CVE, including CVE-2026-110879 and CVE-2026-104016. Earlier Jackson advisories were assigned by GitHub's CNA.

Taking Action on EOL Jackson Versions

Start by finding out what you actually run. Your declared Jackson version and your resolved Jackson version are often different, especially under Spring Boot dependency management, so check the dependency tree for every service, not the POM.

Then sort by branch. If you are on an open branch, get to the October 17-18, 2026 patch releases (2.18.12, 2.21.8, 2.22.4, 3.1.8, or 3.2.4) now, because CVE-2026-110879 is a 9.8. If you are on 2.18, put the move to 2.21 or 3.1 on the calendar before the end of 2026. If you are on a closed branch, decide whether you are upgrading Jackson alone, upgrading the framework that pins it, or running a patched build while you plan.

If your services are on Jackson 2.13, 2.14, or 2.15 and an upgrade is not realistic this quarter, NES for Jackson gives you patched drop-in builds with SLA-backed CVE fixes and VEX statements for your scanners. Those builds come from the team that publishes Jackson's CVEs. To talk through your options, contact HeroDevs.

‍