7 New Vulnerabilities in Jackson in One Day: This Is What AI-Assisted Security Research Looks Like

Author: Steve Poole

Original post on Foojay: Read More

Quick version check: the affected range for all seven is broadly >=2.10.0 =2.19.0 =3.0.0 <3.1.4 — with some CVEs affecting narrower ranges. If you’re on a supported release, upgrade to 2.18.8, 2.21.4, or 3.1.4. If you’re on an EOL line — 2.13.x, 2.14.x, 2.15.x — jump to the bottom of the page for more specifics or visit HeroDevs Jackson Support


Not a sales pitch

Anyone who knows me knows I dont do that. In this case I’m pointing you at HeroDevs because the Jackson issues are serious, HeroDevs have a solution thats stupidly easy to use and I know the folks behind the fixes. It takes a particular type of engineer to create security fixes and I know they have that skillset. Do your own research.

What Just Happened

On 22 June 2026, seven vulnerabilities in jackson-databind were published. All fixed in the same June 4th releases, all credited to a single researcher. Two critical-level RCEs. Five further access control and deserialization issues. One research effort, one codebase, seven findings.

Sounds like a fairytale?

In a recent article, I argued that four converging forces were breaking the old software security equilibrium: CVE volume, AI-assisted discovery, an overwhelmed maintainer community, and regulators running out of patience.

This batch is that argument made concrete.

How findings like this are now getting made

The short version: give a capable AI model the right context, remove the restrictions that exist to prevent misuse, and point it at a codebase. It reasons about trust boundaries, validator assumptions, and edge cases the way a senior security engineer would. But faster, and without getting bored or distracted.

This is mainstream

Both Anthropic and OpenAI now run formal programmes for exactly this. Anthropic’s Cyber Verification Program unlocks dual-use security capabilities for credentialed professionals. OpenAI’s Trusted Access for Cyber has expanded to thousands of verified defenders. Both are documented, public, and growing.

The result, when it works, is not one finding but many.

FIRST’s mid-year vulnerability forecast, published June 15th, revised its 2026 projection upward to approximately 66,000 CVEs. 46% above what was predicted just four months earlier, driven in part by AI-assisted discovery.

Seven Vulnerabilities

All seven are fixed in jackson-databind 2.18.8, 2.21.4, and 3.1.4. All seven were published as GHSAs on June 16th. For EOL versions (2.13.x, 2.14.x, 2.15.x), HeroDevs NES fixes are available for the two critical RCEs now, with the remaining five to follow.

The Critical RCEs

CVE-2026-54512 (GHSA-j3rv-43j4-c7qm) — CVSS v4 9.2 (Critical), EPSS 44%

The PolymorphicTypeValidator allowlist checks the container class name but never validates generic type parameters inside it. Supply java.util.ArrayListArrayList passes the check, the gadget class rides in unchallenged. With a reachable gadget on the classpath, that’s unauthenticated RCE. Affects >=2.10.0. Requires polymorphic typing enabled with a PTV allowlist.

CVE-2026-54513 (GHSA-rmj7-2vxq-3g9f) — CVSS v4 9.3 (Critical)

BasicPolymorphicTypeValidator.allowIfSubTypeIsArray() approves any array based only on clazz.isArray() — it never checks the element type against the allowlist. Supply EvilType[] and the validator waves it through. Same class of attack as CVE-2026-54512, different entry point. Affects >=2.10.0. Also requires polymorphic typing.

Both score Critical under CVSS v4. The CVSS v3.1 scores are 8.1 (High) due to Attack Complexity: High, reflecting the prerequisite that polymorphic deserialization must be enabled.

The Access Control and Deserialization Bypasses

CVE-2026-54514 (GHSA-hgj6-7826-r7m5) — CVSS 5.3 (Medium)

InetSocketAddress deserialization triggers an eager DNS lookup at construction time — before any application-level validation. Attacker-controlled hostname in JSON causes an outbound DNS query. SSRF. Affects >=2.0.0. No polymorphic typing required.

CVE-2026-54515 (GHSA-5jmj-h7xm-6q6v) — CVSS 5.3 (Medium)

Case-insensitive deserialization (@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds _beanProperties from the unfiltered map rather than the contextual one, restoring properties that @JsonIgnoreProperties had just removed. Mass-assignment bypass. Affects >=3.1.0 only.

CVE-2026-54516 (GHSA-9fxm-vc8v-hj55) — CVSS 5.3 (Medium)

A property with @JsonProperty("renamed") on the getter and @JsonIgnore on the setter gets renamed rather than dropped. With INFER_PROPERTY_MUTATORS enabled (default), the private backing field is retained and made writable. Attacker supplies the renamed key, field is set directly, bypassing the @JsonIgnore. Property tampering. Affects >=2.21.0 and >=3.0.0.

CVE-2026-54517 (GHSA-5hh8-q8hv-fr38) — CVSS 5.3 (Medium)

@JsonView filter applied only to creator properties in _deserializeUsingPropertyBased; the setterless collection path bypasses it entirely. A setterless collection annotated with a restricted @JsonView can be written from untrusted JSON. Access control bypass. Affects >=2.21.0 and >=3.0.0.

CVE-2026-54518 (GHSA-rcqc-6cw3-h962) — CVSS 6.5 (Medium)

UnwrappedPropertyHandler.processUnwrappedCreatorProperties() replays buffered JSON into creator parameters without checking prop.visibleInView(activeView). Constructor parameters annotated with both @JsonView and @JsonUnwrapped get populated from attacker JSON even when a restrictive view is active. Access control bypass. Affects >=2.21.0 and >=3.0.0.


The Validator Is the Vulnerability

The two critical RCEs are the most serious findings, but all seven share a common thread: Jackson’s own annotation-based security mechanisms are the attack surface.

CVE-2026-54512 and CVE-2026-54513 bypass the PolymorphicTypeValidator — introduced after a well-documented series of high-severity deserialization CVEs stretching from 2017 to 2019. The bug in CVE-2026-54512 dates to 2019 — introduced with the same release, 2.10, that brought the validator itself.

CVE-2026-54515 through CVE-2026-54518 bypass @JsonIgnoreProperties, @JsonIgnore, and @JsonView — the annotation-based access control mechanisms developers use to keep fields unwritable from untrusted input.

The pattern is the same across all seven: a security boundary that looks closed is open in edge cases the original implementation didn’t anticipate. “I added the validator” and “I annotated the field” are the beginnings of a security posture, not the ends of one.


The Creaking Disclosure Pipeline

The CVE pipeline , which most people rely on without knowing it, has multiple steps beyond the fix itself. A CNA assigns an ID, NVD enriches it, and security scanners – from Dependabot to Snyk, to your SCA tool all sit downstream.

The OSS fixes shipped on June 4th. GHSAs were published June 16th. On 23 June, a third party filed an issue on the GitHub Advisory Database noting that none of the seven had propagated to the global database. Since then, at least the two critical CVEs have begun appearing in scanner databases. Snyk at least is now showing both. The pipeline moved, but it took time.

Most modern scanners have moved away from pure NVD dependence. Dependabot pulls from the GitHub Advisory Database directly, as do at least Trivy, Snyk, and Orca.

But NVD enrichment provides something those sources don’t always carry and which is vital to you: CVSS scores, CPE matching data, and the context security teams use to prioritise remediation.

NIST acknowledged in April 2026 that CVE submissions have grown 263% since 2020 and NVD can no longer enrich all of them.

Don’t assume your scanner’s silence, or its alert, tells the whole story. Check your jackson-databind version directly.


Who’s Effected

Supported (2.18.x, 2.21.x, 3.x) EOL (2.13.x, 2.14.x, 2.15.x)
CVE IDs All seven Same CVE IDs
OSS fix ✅ 2.18.8, 2.21.4, 3.1.4 ❌ None
NES fix (critical RCEs) ✅ 2.13.6, 2.14.4, 2.15.5
NES fix (remaining five) In progress

If you’re on a supported release — upgrade to 2.18.8, 2.21.4, or 3.1.4. All seven resolved.

If you use polymorphic deserializationactivateDefaultTyping() or @JsonTypeInfo — the two critical RCEs are directly relevant. Patch immediately.

If you use @JsonView, @JsonIgnore, or @JsonIgnoreProperties as security boundaries on writable fields, audit whether the five access control CVEs affect your configuration.

If you are on an EOL stream

That’s 2.13.x, 2.14.x, or 2.15.x, there is no community fix. The same CVE that prompts a team on 2.18.7 to upgrade in an afternoon sits unfixed for a team on 2.14.x with nowhere to go. Your options are migration, mitigations, or commercial support. NES for Jackson has backported fixes for the two critical RCEs to 2.13.6, 2.14.4, and 2.15.5. Use the HeroDevs EOL Dataset or endoflife.date to understand your full exposure.

What This Actually Means

Seven vulnerabilities in jackson-databind, one researcher, one day. All fixed before the advisories were published. Some still not visible yet to the full ecosystem.

This is not a one-off. The formal infrastructure for AI-assisted security research now exists at scale. The libraries that haven’t been looked at carefully in years are not safe, they’re simply unexamined. The absence of CVEs was never evidence of safety. It was evidence of silence.

That silence is ending. It’s really time to know your dependencies their versions and their EOL status.

Just do it?

You’ve got a scanner, an SCA tool and in anycase you can just generate an SBOM and use that. It’s easy to do – why wait. Use the HeroDevs EOL Dataset or endoflife.date

Having said that , I will be back with a EOL tooling / data article to help with getting started.

The post 7 New Vulnerabilities in Jackson in One Day: This Is What AI-Assisted Security Research Looks Like appeared first on foojay.