Exploit discussion active in current signal (1 latest mentions)
Recommended action window: High priority (within 72h)
NVD description
Improper Verification of Cryptographic Signature vulnerability in erlef oidcc allows an unauthenticated attacker to impersonate an arbitrary user via an encrypted ID token or JARM response carrying no nested signature. OpenID Connect Core 1.0 section 2 requires that an encrypted ID token be signed then encrypted, with the result being a Nested JWT, and JARM processing rule 5 requires the client to check the signature unconditionally. oidcc instead accepted a JWE wrapping unsigned claims as fully validated, so anyone holding the relying party's public encryption key could mint a token with an arbitrary sub, iss, and aud without possessing the provider's signing key. In oidcc_jwt_util:verify_decrypted_token/4, a decrypted payload that is not a signed JWS fell back to parsing the plaintext claims and returning them with no verifying key. oidcc_token:int_validate_jwt/4 then matched on the JOSE structure type rather than on whether a signature had been verified, and returned success. The JARM path in oidcc_token:validate_jarm/3 is reachable through the browser front channel. UserInfo responses are not affected, because OpenID Connect Core 1.0 section 5.3.2 permits them to be encrypted without also being signed. This issue affects oidcc: from 3.2.0-beta.1 before 3.9.0.
Priority
LOW
Exploitation
NONE
PoC
YES
Patch
AVAILABLE
Momentum
STABLE
| Date | Total | Labels |
|---|
| 2026-08-30 | 1 | Disclosure1 |
| 2026-08-31 | 1 | General1 |
Some increased actor activities are shown targeting erlef oidcc (CVE-2026-75759) https://vuldb.com/vuln/397079/cti
Post summary
The post reports observed intruder activity targeting CVE-2026-75759 and links to a vulnerability page, but lacks concrete exploit details, patch information, or proof of active exploitation.
🚨 IDENTITY SECURITY — NEW OIDC FLAW CAN LET AN ATTACKER IMPERSONATE AN ARBITRARY USER The attacker does NOT need the identity provider's signing key. CyberSignal Priority: 🔴 VERY HIGH 📅 August 30, 2026 🆔 CVE-2026-75759 🏷️ OpenID Connect · Authentication · JWT · JARM · Identity Security 📦 Product: erlef oidcc 📊 CVSS 4.0: 7.6 HIGH ### 🔎 What happened A newly published vulnerability in the `oidcc` OpenID Connect client library can cause an encrypted identity token to be accepted even when the required nested digital signature is missing. In a correctly implemented OpenID Connect flow: claims ↓ digitally signed ↓ signed JWT ↓ encrypted ↓ validated by relying party But vulnerable `oidcc` versions could accept: attacker-controlled claims ↓ NO valid provider signature ↓ encrypted as JWE ↓ accepted as authenticated identity ### ⚔️ Attack chain Obtain relying party's public encryption key ↓ Create arbitrary identity claims ↓ Choose attacker-controlled `sub`, `iss` and `aud` ↓ Wrap unsigned claims inside encrypted JWE ↓ Send token / JARM response ↓ oidcc decrypts payload ↓ signature verification is effectively skipped ↓ attacker impersonates chosen user The attacker does not need possession of the legitimate identity provider's signing key. ### 🎯 What is affected `oidcc`: 3.2.0-beta.1 ↓ versions before 3.9.0 Version 3.9.0 contains the fix. UserInfo responses are not affected by this specific issue because OpenID Connect permits encrypted UserInfo responses without requiring them to also be signed. ### 🧠 Why this matters Modern authentication increasingly depends on one assumption: A valid-looking identity token must prove who issued it. Encryption alone does NOT provide that proof. Encryption protects confidentiality. A digital signature provides authenticity. Confusing the two can turn an authentication protocol into an impersonation primitive. ### ⚠️ Important caveat There is currently no evidence presented in the disclosure showing mass exploitation in the wild. This is a newly published vulnerability, not a confirmed active-exploitation campaign. ### 🛡️ Defender action Organizations using `oidcc` should: • upgrade to 3.9.0 or newer • inventory services using OIDC/JARM • verify encrypted ID tokens are also signature-validated • review authentication logs for abnormal issuer / subject combinations • ensure identity validation depends on verified cryptographic signatures, not simply successful decryption CyberSignal Insight: **Encrypted does not mean authenticated. A token can be private and still be forged.** Sources: EEF CNA · CVE · SANS Internet Storm Center
Post summary
A newly discovered flaw in the oidcc OpenID Connect client allows attackers to forge identity tokens without the provider’s signing key; upgrading to 3.9.0 or newer mitigates the issue, and no active exploitation is reported.