Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ujson.dumps() (or ujson.dump() or ujson.encode()) have a rejectbytes=False option. When set, they may accept malformed or truncated UTF-8 byte sequences, silently rewriting them into different Unicode characters instead of rejecting them. This leads to input validation bypass and data integrity issues. Details The expected behavior is that for x being any bytes string, x == ujson.loads(ujson.dumps(x, rejectbytes=False)).encode(errors="surrogatepass") should always either be true or ujson.dumps() will throw an exception. In reality, some strings which should've been errors are silently rewritten as other strings: Invalid continuation bytes are replaced with valid ones: b'\xcf\x13' - b'\xcf\x93' Unterminated sequence completes the sequence: b'\xc3' - b'\xc3\x80' ... or leads to reading past the end of string: b'\xf0\x90\x94' - b"\xf0\x90\x94\x80inxcontrib'" Impact An application relying on rejectbytes=False for UTF-8 handling may experience: - Data integrity issues - Experience…
Recommended action: Upgrade to 5.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ujson.dump() writes to a file-like object and the write operation raises an exception, the serialized JSON string object is not decremented, leaking memory. Each failed write operation leaks the full size of the serialized payload. Code that uses ujson.dumps() rather than ujson.dump() or only JSON load/decode methods is unaffected. Details Vulnerability Location: - src/ujson/python/objToJSON.c:913 - objToJSONFile() function start - src/ujson/python/objToJSON.c:931 - Error return on write failure - src/ujson/python/objToJSON.c:942 - Early return without cleanup Root Cause: The objToJSONFile() function allocates a Python string object via ujsondumpsinternal(), calls the file's write() method, and returns early if write() raises an exception—but never calls PyDECREF(string) on the early exit path. PoC Impact Any application that serializes data through ujson.dump() to an attacker-influenced file-like object that can fail can be driven into linear memory growth. An attacker…
Recommended action: Upgrade to 5.12.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ujson.dumps() crashes the Python interpreter (segmentation fault) when the product of the indent parameter and the nested depth of the input exceeds INT32MAX. It can also get stuck in an infinite loop if the indent is a large negative number. Both are caused by an integer overflow/underflow whilst calculating how much memory to reserve for indentation. And both can be used to achieve denial of service. (Note: A negative indent to ujson means add spaces after colons but do not add line breaks or indentation. It is unclear to the current maintainers whether this was ever even an intended feature or just a byproduct of the way it was written.) Exploitability To be vulnerable, a service must call ujson.dump()/ujson.dumps()/ujson.encode() whilst giving untrusted users control over the indent parameter and not restrict that indentation to reasonably small non-negative values. (Even with the fix for this vulnerability, such usage is strongly advised against since even a bug-free…
Recommended action: Upgrade to 5.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ujson 5.4.0 to 5.11.0 inclusive contain an accumulating memory leak in JSON parsing large (outside of the range [-2^63, 2^64 - 1]) integers. Exploitability Any service that calls ujson.load()/ujson.loads()/ujson.decode() on untrusted inputs is affected and vulnerable to denial of service attacks. Details 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.getintmaxstrdigits() 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. Fix The leak is fixed in ujson 5.12.0 (4baeb950df780092bd3c89fc702a868e99a3a1d2). There are no workarounds beyond upgrading to an unaffected version. Credits Discovered by Cameron Criswell/Skevros using Coverage-guided fuzzing (libFuzzer + AddressSanitizer)
Recommended action: Upgrade to 5.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? Anyone parsing JSON from an untrusted source is vulnerable. JSON strings that contain escaped surrogate characters not part of a proper surrogate pair were decoded incorrectly. Besides corrupting strings, this allowed for potential key confusion and value overwriting in dictionaries. Examples: Patches Has the problem been patched? What versions should users upgrade to? Users should upgrade to UltraJSON 5.4.0. From version 5.4.0, UltraJSON decodes lone surrogates in the same way as the standard library's json module does, preserving them in the parsed output: Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Short of switching to an entirely different JSON library, there are no safe alternatives to upgrading. For more information If you have any questions or comments about this advisory: Open an issue in UltraJSON
Recommended action: Upgrade to 5.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? When an error occurs while reallocating the buffer for string decoding, the buffer gets freed twice. Due to how UltraJSON uses the internal decoder, this double free is impossible to trigger from Python. Patches Has the problem been patched? What versions should users upgrade to? Users should upgrade to UltraJSON 5.4.0. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? There is no workaround. For more information If you have any questions or comments about this advisory: Open an issue in UltraJSON
Recommended action: Upgrade to 5.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
UltraJSON (aka ujson) 1.34 through 5.1.0 has a stack-based buffer overflow in BufferAppendIndentUnchecked (called from encode).
Recommended action: Upgrade to 5.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.