{"answers":{"affected":"2 open source packages ship an affected version, including tools.jackson.core:jackson-core.","exploited":"There is no known exploitation of GHSA-2m67-wjpj-xhg9 in the wild and no public exploit code.","fix":"Upgrade tools.jackson.core:jackson-core to 3.1.1 or later.","what":"GHSA-2m67-wjpj-xhg9 is a denial of service vulnerability in tools.jackson.core:jackson-core, published on 4 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-2m67-wjpj-xhg9 and fix it if it is affected.\n\nWhat it is: GHSA-2m67-wjpj-xhg9 is a denial of service vulnerability in tools.jackson.core:jackson-core, published on 4 Apr 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-2m67-wjpj-xhg9 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- tools.jackson.core:jackson-core (Maven): affected from 3.0.0; fixed in 3.1.1\n- tools.jackson.core:jackson-core (Maven): affected from 3.0.0; fixed in 3.1.1\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/ (Markdown: https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/index.md)","id":"GHSA-2m67-wjpj-xhg9","markdown":"https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/index.md","name":"GHSA-2m67-wjpj-xhg9","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":true,"product_category":"Java JSON library","requires_auth":"none","summary":"Jackson Core fails to enforce document length limits in certain parsers, allowing attackers to bypass DoS protections and cause resource exhaustion.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Summary\n\nJackson Core 3.x does not consistently enforce `StreamReadConstraints.maxDocumentLength`. Oversized JSON documents can be accepted without a `StreamConstraintsException` in multiple parser entry points, which allows configured size limits to be bypassed and weakens denial-of-service protections.\n\n## Details\n\nThree code paths where `maxDocumentLength` is not fully enforced:\n\n### 1. Blocking parsers skip validation of the final in-memory buffer\n\nBlocking parsers validate only previously processed buffers, not the final in-memory buffer:\n\n- `ReaderBasedJsonParser.java:255`\n- `UTF8StreamJsonParser.java:208`\n\nRelevant code:\n\n```java\n_currInputProcessed += bufSize;\n_streamReadConstraints.validateDocumentLength(_currInputProcessed);\n```\n\nThis means the check occurs only when a completed buffer is rolled over. If an oversized document is fully contained in the final buffer, parsing can complete without any document-length exception.\n\n### 2. Async parsers skip validation of the final chunk on end-of-input\n\nAsync parsers validate previously processed chunks, but do not validate the final chunk on end-of-input:\n\n- `NonBlockingByteArrayJsonParser.java:49`\n- `NonBlockingByteBufferJsonParser.java:57`\n- `NonBlockingUtf8JsonParserBase.java:75`\n\nRelevant code:\n\n```java\n_currInputProcessed += _origBufferLen;\n_streamReadConstraints.validateDocumentLength(_currInputProcessed);\n\npublic void endOfInput() {\n    _endOfInput = true;\n}\n```\n\n`endOfInput()` marks EOF but does not perform a final `validateDocumentLength(...)` call, so an oversized last chunk is accepted.\n\n### 3. DataInput parser path does not enforce `maxDocumentLength` at all\n\n- `JsonFactory.java:457`\n\nRelevant construction path:\n\n```java\nint firstByte = ByteSourceJsonBootstrapper.skipUTF8BOM(input);\nreturn new UTF8DataInputJsonParser(readCtxt, ioCtxt,\n        readCtxt.getStreamReadFeatures(_streamReadFeatures),\n        readCtxt.getFormatReadFeatures(_formatReadFeatures),\n        input, can, firstByte);\n```\n\n`UTF8DataInputJsonParser` does not call `StreamReadConstraints.validateDocumentLength(...)`, so `maxDocumentLength` is effectively disabled for `createParser(..., DataInput)` users.\n\n\u003e **Note:** This issue appears distinct from the recently published nesting-depth and number-length constraint advisories because it affects document-length enforcement.\n\n## PoC\n\n### Async path reproducer\n\n```java\nimport java.nio.charset.StandardCharsets;\nimport tools.jackson.core.JsonParser;\nimport tools.jackson.core.ObjectReadContext;\nimport tools.jackson.core.StreamReadConstraints;\nimport tools.jackson.core.async.ByteArrayFeeder;\nimport tools.jackson.core.json.JsonFactory;\n\npublic class Poc {\n    public static void main(String[] args) throws Exception {\n        JsonFactory factory = JsonFactory.builder()\n                .streamReadConstraints(StreamReadConstraints.builder()\n                        .maxDocumentLength(10L)\n                        .build())\n                .build();\n\n        byte[] doc = \"{\\\"a\\\":1,\\\"b\\\":2}\".getBytes(StandardCharsets.UTF_8);\n\n        try (JsonParser p = factory.createNonBlockingByteArrayParser(ObjectReadContext.empty())) {\n            ByteArrayFeeder feeder = (ByteArrayFeeder) p.nonBlockingInputFeeder();\n            feeder.feedInput(doc, 0, doc.length);\n            feeder.endOfInput();\n\n            while (p.nextToken() != null) { }\n        }\n\n        System.out.println(\"Parsed successfully\");\n    }\n}\n```\n\n- **Expected result:** Parsing should fail because the configured document-length limit is 10, while the input is longer than 10 bytes.\n- **Actual result:** The document is accepted and parsing completes.\n\n### Blocking path reproducer\n\n```java\nimport java.io.ByteArrayInputStream;\nimport java.nio.charset.StandardCharsets;\nimport tools.jackson.core.JsonParser;\nimport tools.jackson.core.StreamReadConstraints;\nimport tools.jackson.core.json.JsonFactory;\n\npublic class Poc2 {\n    public static void main(String[] args) throws Exception {\n        JsonFactory factory = JsonFactory.builder()\n                .streamReadConstraints(StreamReadConstraints.builder()\n                        .maxDocumentLength(10L)\n                        .build())\n                .build();\n\n        byte[] doc = \"{\\\"a\\\":1,\\\"b\\\":2}\".getBytes(StandardCharsets.UTF_8);\n\n        try (JsonParser p = factory.createParser(new ByteArrayInputStream(doc))) {\n            while (p.nextToken() != null) { }\n        }\n\n        System.out.println(\"Parsed successfully\");\n    }\n}\n```\n\n## Impact\n\nApplications that rely on `maxDocumentLength` as a safety control for untrusted JSON can accept oversized inputs without error. In network-facing services this weakens an explicit denial-of-service protection and can increase CPU and memory consumption by allowing larger-than-configured request bodies to be processed.","ecosystems":["Maven"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers","id":"GHSA-2m67-wjpj-xhg9","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Maven","product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Maven","fixed":["3.1.1"],"introduced":["3.0.0"],"last_affected":[],"package":"tools.jackson.core:jackson-core","purl":null,"source":"GHSA-2m67-wjpj-xhg9"},{"ecosystem":"Maven","fixed":["3.1.1"],"introduced":["3.0.0"],"last_affected":[],"package":"tools.jackson.core:jackson-core","purl":"pkg:maven/tools.jackson.core/jackson-core","source":"GHSA-2m67-wjpj-xhg9"}],"products":null,"published":"2026-04-04","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Jackson Core fails to enforce document length limits in certain parsers, allowing attackers to bypass DoS protections and cause resource exhaustion.","url":"https://insights.sbomify.com/GHSA-2m67-wjpj-xhg9/"}