FKIE_CVE-2026-18401

Vulnerability from fkie_nvd - Published: 2026-08-04 15:16 - Updated: 2026-10-23 23:10
Severity
6.9 (Medium) - 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
Summary
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
References
36c7be3b-2937-45df-85ea-ca7133ea542chttps://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf
36c7be3b-2937-45df-85ea-ca7133ea542chttps://github.com/FasterXML/jackson-core/pull/1555
36c7be3b-2937-45df-85ea-ca7133ea542chttps://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq
134c704f-9b21-4f2e-91b3-4a467353bcc0https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "com.fasterxml.jackson.core:jackson-core",
          "product": "jackson-core",
          "programFiles": [
            "src/main/java/com/fasterxml/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java"
          ],
          "programRoutines": [
            {
              "name": "NonBlockingUtf8JsonParserBase._finishNumberIntegralPart"
            },
            {
              "name": "NonBlockingUtf8JsonParserBase._valueComplete"
            }
          ],
          "repo": "https://github.com/FasterXML/jackson-core",
          "vendor": "FasterXML",
          "versions": [
            {
              "lessThanOrEqual": "2.18.5",
              "status": "affected",
              "version": "2.15.0",
              "versionType": "maven"
            },
            {
              "status": "unaffected",
              "version": "2.18.6",
              "versionType": "maven"
            },
            {
              "lessThan": "2.21.1",
              "status": "affected",
              "version": "2.19.0",
              "versionType": "maven"
            },
            {
              "status": "unaffected",
              "version": "2.21.1",
              "versionType": "maven"
            }
          ]
        },
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "defaultStatus": "unaffected",
          "packageName": "tools.jackson.core:jackson-core",
          "product": "jackson-core",
          "programFiles": [
            "src/main/java/tools/jackson/core/json/async/NonBlockingUtf8JsonParserBase.java"
          ],
          "programRoutines": [
            {
              "name": "NonBlockingUtf8JsonParserBase._finishNumberIntegralPart"
            },
            {
              "name": "NonBlockingUtf8JsonParserBase._valueComplete"
            }
          ],
          "repo": "https://github.com/FasterXML/jackson-core",
          "vendor": "FasterXML",
          "versions": [
            {
              "lessThan": "3.1.0",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "maven"
            },
            {
              "status": "unaffected",
              "version": "3.1.0",
              "versionType": "maven"
            }
          ]
        }
      ],
      "source": "36c7be3b-2937-45df-85ea-ca7133ea542c"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.\n\n\n\nThe synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.\n\n\n\nRoot cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.\n\n\n\nImpact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.\n\n\n\nNo privileges or user interaction beyond the ability to submit data for parsing are required.\n\n\n\nThis issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.\n\n\n\nVersions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0."
    },
    {
      "lang": "es",
      "value": "El analizador JSON no bloqueante (as\u00edncrono) en jackson-core no aplica la restricci\u00f3n maxNumberLength definida en StreamReadConstraints (predeterminado: 1000 caracteres). Un atacante capaz de enviar JSON a una aplicaci\u00f3n que utiliza la API del analizador as\u00edncrono puede proporcionar un token num\u00e9rico de longitud arbitraria, lo que lleva a una asignaci\u00f3n excesiva de memoria y un posible agotamiento de la CPU, resultando en una denegaci\u00f3n de servicio.\n\nEl analizador s\u00edncrono aplica este l\u00edmite correctamente, por lo que la restricci\u00f3n se aplica de forma inconsistente dependiendo de qu\u00e9 API de an\u00e1lisis utilice la aplicaci\u00f3n.\n\nCausa ra\u00edz: la ruta de an\u00e1lisis as\u00edncrono en NonBlockingUtf8JsonParserBase y clases relacionadas nunca invoca los m\u00e9todos de validaci\u00f3n de longitud de n\u00fameros. Los m\u00e9todos de an\u00e1lisis de n\u00fameros como _finishNumberIntegralPart() acumulan d\u00edgitos en el TextBuffer sin ninguna verificaci\u00f3n de longitud, luego llaman a _valueComplete() para finalizar el token. _valueComplete() no llama a resetInt() ni a resetFloat(), que son los m\u00e9todos en ParserBase donde se realizan validateIntegerLength() y validateFPLength(). Debido a que ese paso de validaci\u00f3n se omite, maxNumberLength nunca se aplica en la ruta de c\u00f3digo as\u00edncrono.\n\nImpacto: un atacante que env\u00eda un documento JSON que contiene un n\u00famero arbitrariamente largo a una aplicaci\u00f3n que utiliza el analizador as\u00edncrono (por ejemplo, una aplicaci\u00f3n Spring WebFlux u otra aplicaci\u00f3n reactiva) puede causar una asignaci\u00f3n ilimitada en el TextBuffer y un OutOfMemoryError. Si la aplicaci\u00f3n posteriormente llama a getBigIntegerValue() o getDecimalValue(), la JVM puede adem\u00e1s quedar ocupada en el an\u00e1lisis de BigInteger en O(n^2), causando una denegaci\u00f3n de servicio basada en CPU.\n\nNo se requieren privilegios ni interacci\u00f3n del usuario m\u00e1s all\u00e1 de la capacidad de enviar datos para su an\u00e1lisis.\n\nEste problema afecta a com.fasterxml.jackson.core:jackson-core desde la versi\u00f3n 2.15.0 hasta la 2.18.5 y desde la 2.19.0 hasta la 2.21.0, y a tools.jackson.core:jackson-core desde la 3.0.0 hasta la 3.0.x.\n\nLas versiones anteriores a la 2.15.0 no se ven afectadas, porque StreamReadConstraints -- que define la configuraci\u00f3n maxNumberLength -- se introdujo por primera vez en jackson-core 2.15.0, por lo que no existe tal restricci\u00f3n que pueda ser eludida en versiones anteriores. Tenga en cuenta que GHSA-72hv-8253-57qq registra el l\u00edmite inferior del rango 2.x afectado como 2.0.0."
    }
  ],
  "id": "CVE-2026-18401",
  "lastModified": "2026-10-23T23:10:00.157",
  "metrics": {
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 6.9,
          "baseSeverity": "MEDIUM",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
          "version": "4.0",
          "vulnAvailabilityImpact": "LOW",
          "vulnConfidentialityImpact": "NONE",
          "vulnIntegrityImpact": "NONE",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "36c7be3b-2937-45df-85ea-ca7133ea542c",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-18401",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-04T17:58:30.797291Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-04T15:16:29.900",
  "references": [
    {
      "source": "36c7be3b-2937-45df-85ea-ca7133ea542c",
      "url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
    },
    {
      "source": "36c7be3b-2937-45df-85ea-ca7133ea542c",
      "url": "https://github.com/FasterXML/jackson-core/pull/1555"
    },
    {
      "source": "36c7be3b-2937-45df-85ea-ca7133ea542c",
      "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
    }
  ],
  "sourceIdentifier": "36c7be3b-2937-45df-85ea-ca7133ea542c",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-770"
        }
      ],
      "source": "36c7be3b-2937-45df-85ea-ca7133ea542c",
      "type": "Secondary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.