CVE-2026-44660

What it actually does

UltraJSON (ujson) prior to 5.12.1 fails to decrement the reference count of the temporary serialized JSON string when ujson.dump() writes to a file-like object and that write raises. Each failed write therefore leaks memory equal to the full serialized payload. Repeated failures can exhaust process memory and terminate or hang the interpreter, producing a denial-of-service condition. Confidentiality and integrity are not affected.

Why it matters to the business

Python services that encode JSON to files, sockets, or other file-like objects can degrade or crash under repeated write failures, causing outages, lost work, and restart churn. The issue is not in CISA KEV, has no reported ransomware use, and exploit maturity is none; EPSS remains low (~0.006) though it rose about 53% over 30 days. Patching is still warranted wherever ujson is used in long-lived workers, because a single unpatched process can be driven to OOM without stealing data.

How an attack unfolds

An attacker who can reach an application path that calls ujson.dump() on a file-like object they can cause to fail (full disk, broken pipe, permission error, or a write() that raises) triggers the leak. Each exception leaves the entire serialized buffer unreleased. Repeating the request with large payloads grows RSS until the worker is OOM-killed or stops responding. No named threat actors are associated, and there is no public exploit maturity; this is an availability issue, not remote code execution. Unauthenticated reachability depends on whether the dump path is exposed, not on a separate auth bypass in ujson.

How to fix it

Upgrade ultrajson/ujson to 5.12.1 or later, which decrements the serialized string when a write fails. Pin the dependency in lockfiles so it cannot be downgraded. Restart long-running workers after upgrade so previously leaked memory is released. If upgrade is delayed, avoid ujson.dump() to fallible file-like objects: serialize with ujson.dumps() (or the standard library json module) and write with explicit error handling.

How to confirm the fix worked

Confirm the running package is 5.12.1 or newer (pip show ujson; python -c "import ujson; print(ujson.__version__)"). Scan requirements.txt, poetry.lock, Pipfile.lock, and uv.lock for ujson/ultrajson below 5.12.1. In a test process, call dump() against a file-like object whose write() always raises and verify RSS does not grow across many iterations after the patch.

Typical attack path

1. Find an application or job that uses UltraJSON dump() to write JSON to a file, socket, or other file-like object
2. Cause or wait for write() to raise (disk full, EPIPE, permission error, or a raising file-like object)
3. Repeat with large JSON payloads so each failure leaks a full serialized buffer
4. Continue until process memory is exhausted and the service crashes or hangs

How to detect it

This leak has no distinctive network payload or named actor TTPs. Hunt Python processes still running ujson before 5.12.1 and correlate unbounded RSS growth with repeated I/O errors during JSON writes (disk full, broken pipe, permission denied) and subsequent OOM kills in kernel, systemd, or container logs. Application logs may show exceptions originating from ujson.dump or the file-like write path immediately before memory pressure. Absence of KEV listing and exploit maturity of none means opportunistic resource exhaustion is more likely than a signature-based campaign.

What your security team should do

• Inventory Python services that depend on ujson/ultrajson, especially internet-facing or high-throughput JSON writers
• Upgrade to 5.12.1 or later, pin lockfiles, and restart workers
• Fail CI/CD when ujson is below 5.12.1
• Add RSS/OOM alerting on processes that serialize JSON to files or sockets
• Until patched, prefer dumps-then-write or the standard json module for fallible destinations