joserfc EUVD-2026-102310

Exploitation requires that the relying application (1) uses joserfc prior to 1.7.4, (2) processes JWS General JSON Serialization input via joserfc.jws.deserialize_json(), and (3) treats a successful deserialization as proof of authenticity. The attacker needs no signing key and no authentication (PR:N). Limiting factors that reduce real-world exposure: the flaw affects ONLY the General JSON Serialization path - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing are explicitly NOT vulnerable - so applications that only use those APIs are unaffected regardless of version; the application must also accept attacker-controlled serialized JWS and act on the decoded payload.

All available signals point to a genuinely high-priority flaw, with one important scoping caveat. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a network-reachable, trivially-exploitable, unauthenticated condition, which is consistent with the CWE-290 authentication-bypass classification and the root cause: verify_general_json() iterates zero times over an empty signatures array and returns success, so any attacker can forge an 'authenticated' payload with no signing key. This is confirmed by the vendor advisory (GHSA-4pp3-559j-c5c2) and the fix commit. No EPSS score was supplied and the CVE is not in CISA KEV, so there is no evidence of active, widespread exploitation yet - the 9.1 rating reflects potential impact and ease, not observed attacks. The real-world risk is gated by application usage rather than mere installation: it only applies when a relying application calls joserfc.jws.deserialize_json() on attacker-supplied JWS General JSON Serialization and trusts the result. I diverge from NVD on the confidentiality metric: the direct library impact is integrity (a forged payload accepted as authentic); C:H appears to be a downstream/impersonation inference rather than a direct effect - verify with the vendor advisory.

An application uses joserfc < 1.7.4 and calls deserialize_json() to validate JWS General JSON Serialization tokens it receives over the network, trusting a successful return as proof of signature authenticity. An attacker without any key submits a JSON object with an arbitrary payload and an empty "signatures": [] array; the verification loop runs no checks and returns success, so the relying application treats the attacker-chosen payload (e.g. {"user":"admin"}) as authentic. No public in-the-wild exploit is listed, but the fix commit ships a regression test that demonstrates the trivial bypass end-to-end.