Why is Jackson Core 2.22.0 vulnerable while the earlier 2.21.4 is fixed?

[epantke]

I am trying to understand the release sequencing around #1611 and GHSA-r7wm-3cxj-wff9.

The published versions produce this unexpected progression:

2.21.4 (fixed) -> 2.22.0 (vulnerable) -> 2.22.1 (fixed)

This allowed an ordinary automated dependency update from 2.21.4 to 2.22.0 to move downstream applications from a fixed version to a vulnerable version.

Timeline

• May 20, 2026: The fix was merged in Apply number-length validator on streaming integer path of async parser [GHSA-r7wm-3cxj-wff9] #1611.
• May 21: A maintainer listed 2.22.1 as the fixed release for the 2.22 line:
  Apply number-length validator on streaming integer path of async parser [GHSA-r7wm-3cxj-wff9] #1611 (comment)
• May 29: Fixed 2.21.4 was released:
  https://github.com/FasterXML/jackson-core/releases/tag/jackson-core-2.21.4
• June 3: 2.22.0 was released without that fix:
  https://github.com/FasterXML/jackson-core/releases/tag/jackson-core-2.22.0
• July 7: The fixed 2.21 history was merged into 2.22 and 2.22.1 was released:
  https://github.com/FasterXML/jackson-core/releases/tag/jackson-core-2.22.1
• July 21: GHSA-r7wm-3cxj-wff9 became public:
  GHSA-r7wm-3cxj-wff9

The relevant comparison is:

jackson-core-2.22.0...jackson-core-2.22.1

Questions

1. Was 2.22.0 intentionally released without the fix from Apply number-length validator on streaming integer path of async parser [GHSA-r7wm-3cxj-wff9] #1611?
2. Was the 2.22 branch already frozen or otherwise unable to receive the fix?
3. Is this expected behavior across Jackson's parallel release lines?
4. How can downstream consumers identify when a newer Jackson release does not contain a security fix already present in an older line?
5. Could the release process prevent or clearly communicate this situation in the future?

This is not a new vulnerability report. The vulnerability is public and fixed. I am asking to understand the release process because this sequence caused a real downstream security regression through a normal dependency update.

[pjfanning]

the ghsa is wrong - 2.22.0 and 3.2.0 have the fix - I have updated the GHSA - commit 4cdd529 shows the git tags in which the change appears
at least, I updated GHSA-r7wm-3cxj-wff9 but I don't know when these edit will reach GHSA-r7wm-3cxj-wff9 - these 2 links are different despite GitHub making them look the same.

[noren95]

Hi @pjfanning is this GHSA-642r-3gj9-2pj5 the same issue?
This one specifies the vulnerable range (introduced in 2.15.0), while GHSA-r7wm-3cxj-wff9 does not mention that.

If both GHSAs are the same issue, which of them is correct? GHSA-642r-3gj9-2pj5/GHSA-r7wm-3cxj-wff9?
And probably withdrawn the wrong one as duplicate?

[pjfanning]

GH in GHSA stands for GitHub. Ask them why there are 2 GHSAs for this.