A newly disclosed vulnerability in the Erlang oidcc OpenID Connect library could allow an unauthenticated attacker to impersonate users in applications that meet specific encryption-related conditions.
Tracked as CVE-2026-75759, the flaw has a CVSS v4 score of 7.6, rated High. The vulnerability was published on August 30, 2026, and is classified as CWE-347: Improper Verification of Cryptographic Signature.
According to the upstream security advisory, the problem allows a vulnerable application to accept an encrypted JSON Web Token without verifying the signature that is required inside the encrypted token.
OpenID Connect requires an encrypted ID token to be signed before it is encrypted. In other words, the expected structure is a signed JWT that is subsequently encrypted. The vulnerable implementation could instead accept an encrypted JWT containing claims that had never been signed by the trusted OpenID Provider.
The distinction is significant because encryption only protects the contents from unauthorized readers. It does not prove who created the contents.
The vulnerability affects oidcc versions beginning with 3.2.0-beta.1 and before 3.9.0. The affected range therefore includes the 3.8.0 release. The upstream advisory identifies 3.9.0 as the fixed version.
The OSV vulnerability record lists the same affected range and identifies the fixing commit as 5f62fbccdae8526ff62653b8901657a6c1400fd9.
The weakness occurs in the validation path for encrypted JWTs. The advisory identifies oidcc_jwt_util:verify_decrypted_token/4 as one of the affected functions.
When the decrypted content was a valid signed JWS, verification proceeded normally. However, when the plaintext was not a JWS, the vulnerable code could encounter an invalid_jwt_token condition and continue by parsing the claims instead of treating the absence of a valid signature as a fatal error.
The resulting claims could then reach oidcc_token:int_validate_jwt/4. The implementation distinguished between JOSE object types without requiring proof that the encrypted object’s contents had been authenticated by a valid signature.
As a result, claims such as the issuer, audience, subject and token timestamps could be processed even though the trusted identity provider had not signed them.
An attacker does not need to obtain the OpenID Provider’s signing key to exploit the flaw. The upstream advisory says exploitation is possible when the relying party has an encryption key configured and the OpenID Provider advertises the relevant encryption capabilities.
In that situation, an attacker can use the relying party’s public encryption key to create an encrypted token. The attacker can place chosen identity claims inside the token, including an arbitrary sub value, and the vulnerable library can accept those claims as part of the authentication process.
This can lead to impersonation of arbitrary users and, in affected applications, potentially account takeover.
The vulnerability also affects validation of JARM responses, or JWT Secured Authorization Response Mode. The upstream advisory identifies oidcc_token:validate_jarm/3 as another affected path.
The JARM validation path is significant because authorization responses are delivered through the browser. The maintainers’ analysis states that an encrypted-only JARM response can therefore reach the vulnerable validation logic under the affected configuration.
The fixing code changes the validation behavior so that an encrypted JOSE object without a required signature produces an explicit {error, signature_required} result.
The same protection is applied to the JARM validation path, preventing an encrypted-only response from being accepted as a valid signed response.
The upstream fix also includes regression tests for the attack conditions. One test creates attacker-controlled claims including iss, sub, aud, iat and exp, encrypts them without signing them, and checks that the patched ID-token validation path rejects the result with signature_required.
Another test covers the absence of at_hash, ensuring the rejection occurs because the token lacks the required signature rather than because of an unrelated validation failure.
A separate regression test constructs an encrypted-only JARM response containing an injected authorization code and verifies that the patched implementation also returns signature_required.
The fix deliberately does not reject every encrypted JWT without a signature. The maintainers note that encrypted UserInfo responses are different because OpenID Connect permits UserInfo responses to be encrypted without also being signed.
For that reason, the patch targets the callers that specifically require signatures, including ID-token and JARM validation, while preserving the permitted behavior for UserInfo responses.
The OpenID Connect Core specification defines the required signing and encryption behavior for ID tokens and provides the protocol context behind the fix.
The vulnerability’s CVSS v4 vector is CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. The rating reflects a network-based attack with low complexity and no required attacker privileges, while the attack still depends on specific configuration requirements and user interaction.
The affected condition is not present in every oidcc deployment. The OSV record states that the vulnerable code path is reachable when the OpenID Provider advertises the relevant encryption capabilities and the relying party has an encryption key configured.
For ID tokens, the relevant discovery capabilities include id_token_encryption_alg_values_supported and id_token_encryption_enc_values_supported. For JARM, the corresponding capabilities include authorization_encryption_alg_values_supported and authorization_encryption_enc_values_supported.
Without those conditions, the vulnerable decryption path is not reached in the same way.
The vulnerability was reported by EQSTLab. The Erlang Ecosystem Foundation credits Jonatan Männchen with remediation and coordination.
The fixing commit changes src/oidcc_jwt_util.erl, src/oidcc_token.erl and test/oidcc_token_test.erl. The patch adds explicit signature enforcement and corresponding regression coverage.
Organizations using oidcc should review their deployed version and encryption configuration. The upstream project identifies 3.9.0 as the fixed release, while versions from 3.2.0-beta.1 through 3.8.0 are affected.
There is also a release-distribution timing detail worth noting. At the time of the reviewed package metadata, the Hex package page still showed 3.8.0 as the latest package version, even though the security advisory and fixing commit identify 3.9.0 as the fixed version.
The upstream repository’s release information likewise still surfaced 3.8.0 as the latest formal release in the material reviewed. This indicates that the security fix and its public advisory were available before the package and release metadata had fully caught up.
There was no reliable evidence in the reviewed sources indicating active exploitation of CVE-2026-75759 in the wild at the time of publication.
The immediate security recommendation is to move affected deployments to the fixed 3.9.0 code when available through the relevant distribution channel, or use the upstream fixed code when maintaining a build directly from the repository.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
