CVE-2026-32875

What it actually does

UltraJSON (ujson) versions 5.10 through 5.11.0 contain an integer overflow and underflow in the C encoder when computing how much memory to reserve for indentation. If the product of the indent argument and the nesting depth of the input exceeds INT32_MAX, a buffer overflow occurs and the Python interpreter aborts with a segmentation fault. A large negative indent underflows the same calculation and can stall the encoder in an infinite loop. Both outcomes are process-level denial of service only: confidentiality and integrity are not affected, and there is no indicated path to remote code execution. A service is exposed only if it calls ujson.dump(), ujson.dumps(), or ujson.encode() with an untrusted or unbounded indent, or if it uses a fixed negative indent on nested input.

Why it matters to the business

Python APIs and workers that pretty-print JSON with UltraJSON can be taken offline by a single crafted request, causing worker crashes, restart storms, request timeouts, and loss of availability. Impact is highest where indent is taken from query parameters, request bodies, or debug flags and where UltraJSON is a direct or transitive dependency of many services. The issue is not in CISA KEV, is not associated with ransomware, and has no public exploit maturity, so urgency is driven by availability rather than known mass exploitation. EPSS is still low at 0.0077 but rose about 64% over 30 days, and the CVE has been public for roughly 200 days—long enough that remaining 5.10–5.11.0 deployments are an avoidable reliability risk.

How an attack unfolds

An unauthenticated client finds an HTTP or RPC endpoint that serializes responses with UltraJSON and either forwards a client-supplied indent/pretty-print option into dump, dumps, or encode, or uses a fixed negative indent. The client sends nested JSON together with an extremely large positive indent so that indent multiplied by depth overflows a 32-bit integer, or with a large negative indent that underflows the reservation math. The native encoder then either overflows the indentation buffer and kills the interpreter, or never returns. Repeating the request against load-balanced workers exhausts capacity. No credentials or user interaction are required when indent is exposed on the network. No named threat actors or campaigns are associated with this CVE, and exploitation yields denial of service rather than access to data or code execution.

How to fix it

Upgrade the ultrajson package to 5.12.0 or later everywhere it is declared or pulled in transitively, and refresh lockfiles (pip, poetry, pipenv, uv, conda) so 5.10–5.11.0 cannot be reintroduced. Until the upgrade is complete, stop passing any client-controlled value into the indent parameter of ujson.dump(), ujson.dumps(), or ujson.encode(); clamp indent to a small non-negative range or omit it; and remove any fixed negative indent. Treat remaining 5.10–5.11.0 pins as a production availability defect.

How to confirm the fix worked

Inventory Python environments and container images for ultrajson 5.10 through 5.11.0 and confirm the resolved version is 5.12.0 or newer. Grep application code and wrappers for dump, dumps, and encode call sites that take indent from request input, configuration, or a negative constant. After upgrading, regression-test legitimate pretty-print paths with small non-negative indents and nested documents, and verify workers no longer crash or hang on encode. Do not use unbounded or negative indent values as a production test.

Typical attack path

1. Locate a service that encodes JSON with UltraJSON and accepts an indent or pretty-print option from the client, or that hard-codes a negative indent.
2. Send nested JSON while supplying an unbounded positive indent or a large negative indent to dump, dumps, or encode.
3. Trigger a native crash (segmentation fault) or an encoder hang in the Python worker.
4. Repeat against multiple workers or instances so process managers restart into the same failing path and legitimate traffic is denied.

How to detect it

Hunt for historical denial of service rather than post-exploitation malware. Review application, reverse-proxy, and access logs around JSON encode or pretty-print endpoints for requests that set an indent (or equivalent pretty-print) parameter to a negative number or to a value far above normal pretty-print ranges, clustered with 5xx responses, worker timeouts, or sudden process exits. On hosts, look at systemd/journald, container runtime, and orchestrator events for Python workers exiting with SIGSEGV or remaining unresponsive on CPU while encoding JSON. Core dumps, fatal interpreter logs, and native stack frames in the ujson extension around dumps/encode are the primary artifacts; there is no known persistence, implant, or named actor TTPs for this CVE. Correlate spikes in restart counts for services that still resolve ultrajson 5.10–5.11.0.

• ujson.dumps
• ujson.dump
• ujson.encode
• Fatal Python error
• Segmentation fault
• SIGSEGV
• indent=-
• "indent":-
• indent=2147483647
• indent=2147483646
• libujson
• _ujson*.so

What your security team should do

• Patch ultrajson to 5.12.0 or later in all direct and transitive dependencies and block 5.10–5.11.0 in package policy.
• Find and change every dump/dumps/encode call so indent cannot come from untrusted input and is never negative.
• Prioritize internet-facing Python APIs and high-churn worker pools; remaining unpatched hosts after ~200 days of public disclosure are an availability incident waiting to happen.
• Watch EPSS and crash telemetry; the 30-day rise is a signal to finish rollout even though KEV and ransomware flags are false.
• Add dependency scanning and SBOM checks so future UltraJSON releases are absorbed before similar encoder bugs recur.