CVE-2026-32874: UltraJSON has a Memory Leak parsing large integers allows DoS
UltraJSON is a fast JSON encoder and decoder written in pure C with bindings for Python 3.7+. Versions 5.4.0 through 5.11.0 contain an accumulating memory leak in JSON parsing large (outside of the range [-2^63, 2^64 - 1]) integers. The leaked memory is a copy of the string form of the integer plus an additional NULL byte. The leak occurs irrespective of whether the integer parses successfully or is rejected due to having more than sys.get_int_max_str_digits() digits, meaning that any sized leak per malicious JSON can be achieved provided that there is no limit on the overall size of the payload. Any service that calls ujson.load()/ujson.loads()/ujson.decode() on untrusted inputs is affected and vulnerable to denial of service attacks. This issue has been fixed in version 5.12.0.
Security readout for executives and security teams
Plain-English summary
UltraJSON versions 5.4.0 through 5.11.0 can leak memory when parsing very large integers in JSON. Internet-facing services that parse untrusted JSON with ujson can be forced to consume memory until availability is affected. The vendor fixed the issue in 5.12.0.
Executive priority
Prioritize remediation for public or partner-facing Python APIs using UltraJSON. The issue is straightforward denial of service, not data theft, but affected services can lose availability under malicious input.
Technical view
The bug is an accumulating memory leak in ujson.load(), ujson.loads(), and ujson.decode() when parsing integers outside [-2^63, 2^64 - 1]. The leak includes the integer string plus a NULL byte and occurs even when Python rejects oversized digit counts. Impact is availability only: CVSS 7.5, CWE-401/CWE-772.
Likely exposure
Exposure is most likely in Python services using ultrajson/ujson 5.4.0 through 5.11.0 on untrusted JSON, especially public APIs without strict body-size limits.
Exploitation context
The source bundle does not show CISA KEV listing or confirmed active exploitation. Abuse would depend on reaching a parser path with large attacker-controlled JSON input and sufficient request size allowance.
Researcher notes
Key evidence comes from the GitHub advisory, CVE record, release note, and fixing commit. The bundle names no exploit in the wild. Scope should remain limited to ultrajson 5.4.0 through 5.11.0 and untrusted JSON parsing paths.
Mitigation direction
Upgrade ultrajson to version 5.12.0 or later.
Apply vendor or distribution guidance for packaged ultrajson builds.
Limit maximum JSON request body size at application and edge layers.
Avoid parsing untrusted JSON with affected ujson versions until upgraded.
Monitor memory growth and worker restarts on JSON-heavy endpoints.
Validation and detection
Inventory Python dependencies for ultrajson or ujson versions 5.4.0 through 5.11.0.
Trace externally reachable code paths calling ujson.load, ujson.loads, or ujson.decode.
Confirm request size limits exist before JSON parsing occurs.
Verify deployed artifacts use ultrajson 5.12.0 or later.
Review Red Hat package status where distribution packages are used.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-401: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.