joserfc: Compact JWS size guard allocates attacker-controlled segments before rejection
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.7.6
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The joserfc Python library, which implements JOSE standards such as JSON Web Signatures, is affected when it processes compact-format JWS tokens from untrusted input. An attacker can send oversized tokens that cause the library to allocate excessive memory before the size check rejects them, which could exhaust process memory and make the service unavailable.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.6, joserfc compact JWS deserialization calls bytes.split() before enforcing the existing aggregate segment-size limits. When attacker-controlled compact serialization bytes reach deserialize_compact(), the split creates copies of the header, payload, and signature segments before ExceededSizeError rejects them, causing an additional allocation approximately proportional to the supplied token. Requests that exhaust available process memory can therefore cause an availability failure even though signature verification fails. This issue is fixed in version 1.7.6.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- authlib joserfc
fixed in 1.7.6