[GHSA-5jmj-h7xm-6q6v] jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties

[snieguu]

Updates

• Affected products

Comments
Version 2.21.5 has not been released yet, which may cause confusion:

• Updating to this version is not possible
• Security scanners may report that a fix is available

See: https://github.com/FasterXML/jackson-databind/tags

[github]

Hi there @cowtowncoder! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[chadlwilson]

Personally I don't think this is a good idea or necessary.

There is 99% confidence it'll be fixed in 2.21.5 since it has already been merged, whereas "last known" conveys uncertainty about whether it will be fixed and requires more manual effort for the maintainer to update the advisory to be more accurate once releases are completed.

It's also inconsistent with the other unreleased backports (2.18, 2.22) which creates additional confusion, not less.

[shivasai09]

@snieguu , when will the version 2.21.5 release?

our org has reported the CVE [CVE-2026-54515] , and it has adviced to use the above version, but i don't see it release yet. is there any pipeline we can track through for it's release ?

@chadlwilson

[chadlwilson]

@snieguu , when will the version 2.21.5 release?

@shivasai09 We are all just community members. You need to find a way to subscribe to Maven releases, or use something like dependabot/renovate which will automatically raise PRs/MRs when available.

Tell "your org" there is no fix available and thus ignore/suppress the CVE for a week or two, assuming you're actually vulnerable.,

[snieguu]

Personally I don't think this is a good idea or necessary.

There is 99% confidence it'll be fixed in 2.21.5 since it has already been merged, whereas "last known" conveys uncertainty about whether it will be fixed and requires more manual effort for the maintainer to update the advisory to be more accurate once releases are completed.

It's also inconsistent with the other unreleased backports (2.18, 2.22) which creates additional confusion, not less.

@chadlwilson 2.18.9 should definitely be removed as well. Since 2.22.1 is not mentioned in the advisory, it should not cause any confusion. Personally, I think claiming that a CVE is fixed in a version that does not actually exist creates even more confusion(at least on the consumer side of the software)

[chadlwilson]

No-one really pays attention to the semantics here, they just look at the output of the dumb tools we are all reliant on which will still report the same vulnerabilities. Vuln disclosures make no assertions about binary release status or the distribution mechanism, so to conclude more is reading too much into it.

Right now users can compile 2.21.5 (or 2.18.9 , 2.22.1 etc) themselves off the branch and ship to production - thus fix is available.

You're not helping anything by cresting more admin work for open source maintainers and quibbling about semantics, and assuming incorrectly from "as is" licenses more than is committed to regarding "binary availability".