Package Instance
Lookup for vulnerable packages by Package URL.
GET /api/packages/920078?format=api
{ "url": "http://public2.vulnerablecode.io/api/packages/920078?format=api", "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-core@2.18.0-rc1", "type": "maven", "namespace": "com.fasterxml.jackson.core", "name": "jackson-core", "version": "2.18.0-rc1", "qualifiers": {}, "subpath": "", "is_vulnerable": true, "next_non_vulnerable_version": "2.18.6", "latest_non_vulnerable_version": "2.21.1", "affected_by_vulnerabilities": [ { "url": "http://public2.vulnerablecode.io/api/vulnerabilities/21938?format=api", "vulnerability_id": "VCID-evmb-e63r-rfcy", "summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition\n### Summary\nThe non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n private static final int MAX_NUMBER_LENGTH = 1000;\n private static final int TEST_NUMBER_LENGTH = 5000;\n\n private final JsonFactory factory = new JsonFactory();\n\n // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n @Test\n void syncParserRejectsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n try {\n try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits — UNEXPECTED\");\n }\n }\n }\n fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n } catch (StreamConstraintsException e) {\n System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n }\n }\n\n // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n @Test\n void asyncParserAcceptsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n NonBlockingByteArrayJsonParser p =\n (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n p.feedInput(payload, 0, payload.length);\n p.endOfInput();\n\n boolean foundNumber = false;\n try {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n foundNumber = true;\n String numberText = p.getText();\n assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n }\n }\n // Output to console\n System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits — BUG CONFIRMED\");\n assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n } catch (StreamConstraintsException e) {\n fail(\"Bug is fixed — async parser now correctly rejects long numbers: \" + e.getMessage());\n }\n p.close();\n }\n\n private byte[] buildPayloadWithLongInteger(int numDigits) {\n StringBuilder sb = new StringBuilder(numDigits + 10);\n sb.append(\"{\\\"v\\\":\");\n for (int i = 0; i < numDigits; i++) {\n sb.append((char) ('1' + (i % 9)));\n }\n sb.append('}');\n return sb.toString().getBytes(StandardCharsets.UTF_8);\n }\n}\n\n```\n\n\n### Impact\nA malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:\n1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.\n2. **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.\n\n### Suggested Remediation\n\nThe async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)", "references": [ { "reference_url": "https://github.com/FasterXML/jackson-core", "reference_id": "", "reference_type": "", "scores": [ { "value": "6.9", "scoring_system": "cvssv4", "scoring_elements": "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" }, { "value": "MODERATE", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://github.com/FasterXML/jackson-core" }, { "reference_url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf", "reference_id": "", "reference_type": "", "scores": [ { "value": "6.9", "scoring_system": "cvssv4", "scoring_elements": "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" }, { "value": "MODERATE", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf" }, { "reference_url": "https://github.com/FasterXML/jackson-core/pull/1555", "reference_id": "", "reference_type": "", "scores": [ { "value": "6.9", "scoring_system": "cvssv4", "scoring_elements": "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" }, { "value": "MODERATE", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://github.com/FasterXML/jackson-core/pull/1555" }, { "reference_url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq", "reference_id": "", "reference_type": "", "scores": [ { "value": "MODERATE", "scoring_system": "cvssv3.1_qr", "scoring_elements": "" }, { "value": "6.9", "scoring_system": "cvssv4", "scoring_elements": "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" }, { "value": "MODERATE", "scoring_system": "generic_textual", "scoring_elements": "" } ], "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq" }, { "reference_url": "https://github.com/advisories/GHSA-72hv-8253-57qq", "reference_id": "GHSA-72hv-8253-57qq", "reference_type": "", "scores": [ { "value": "MODERATE", "scoring_system": "cvssv3.1_qr", "scoring_elements": "" } ], "url": "https://github.com/advisories/GHSA-72hv-8253-57qq" } ], "fixed_packages": [ { "url": "http://public2.vulnerablecode.io/api/packages/64511?format=api", "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-core@2.18.6", "is_vulnerable": false, "affected_by_vulnerabilities": [], "resource_url": "http://public2.vulnerablecode.io/packages/pkg:maven/com.fasterxml.jackson.core/jackson-core@2.18.6" }, { "url": "http://public2.vulnerablecode.io/api/packages/64512?format=api", "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-core@2.21.1", "is_vulnerable": false, "affected_by_vulnerabilities": [], "resource_url": "http://public2.vulnerablecode.io/packages/pkg:maven/com.fasterxml.jackson.core/jackson-core@2.21.1" }, { "url": "http://public2.vulnerablecode.io/api/packages/64515?format=api", "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-core@3.1.0", "is_vulnerable": false, "affected_by_vulnerabilities": [], "resource_url": "http://public2.vulnerablecode.io/packages/pkg:maven/com.fasterxml.jackson.core/jackson-core@3.1.0" } ], "aliases": [ "GHSA-72hv-8253-57qq" ], "risk_score": 3.1, "exploitability": "0.5", "weighted_severity": "6.2", "resource_url": "http://public2.vulnerablecode.io/vulnerabilities/VCID-evmb-e63r-rfcy" } ], "fixing_vulnerabilities": [], "risk_score": "3.1", "resource_url": "http://public2.vulnerablecode.io/packages/pkg:maven/com.fasterxml.jackson.core/jackson-core@2.18.0-rc1" }