CVE-2026-13089 in OIDC::Lite
Summary
by MITRE • 07/23/2026
OIDC::Lite versions through 0.12.1 for Perl allow ID Token signature verification bypass via a token-controlled algorithm allowlist in verify.
When the caller does not pin an algorithm, OIDC::Lite::Model::IDToken::verify sets $self->alg($self->header->{alg}) from the token's own header and then calls decode_jwt(token, key, 1, [$self->alg]), handing JSON::WebToken an accepted-algorithm allowlist taken from the untrusted token. A token with alg=none yields ['none'], so decode_jwt returns the claims with no signature check, and a token with alg=HS256 is verified with the RP's RSA public key as the HMAC secret (RS to HS confusion).
The ID Token is the OpenID Connect authentication assertion delivered to the Relying Party. Any caller that verifies an ID Token through the unpinned load(token)->verify path, or load(token, key) with only the key pinned, accepts a forged token carrying attacker-chosen claims such as sub and is authenticated as any user. Passing an explicit algorithm so $self->alg is already set bypasses the header-derived allowlist and is not affected.
Note that the latest version uploaded to CPAN is 0.10. Later versions are available in the git repository.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/23/2026
This vulnerability exists in OIDC::Lite Perl library versions through 0.12.1 where the ID token signature verification mechanism contains a critical flaw allowing attackers to bypass authentication checks entirely. The vulnerability stems from improper handling of JSON Web Token (JWT) algorithm validation during the verification process, creating a scenario where untrusted token data directly controls the acceptable algorithms for signature verification.
The technical flaw occurs when the verify method processes ID tokens without an explicitly pinned algorithm. In this case, the library extracts the algorithm value from the token's header field and assigns it to $self->alg before invoking decode_jwt with a parameter that uses this potentially malicious value as an allowlist of accepted algorithms. This design creates a dangerous trust relationship where the token itself controls its own verification parameters, making the system vulnerable to algorithm confusion attacks.
When an attacker crafts a token with alg=none, the system accepts ['none'] as the only allowed algorithm and proceeds to decode the JWT without performing any signature validation at all. This effectively nullifies the security mechanism designed to prevent unauthorized token manipulation. Additionally, when a token specifies alg=HS256, the system incorrectly uses the relying party's RSA public key as an HMAC secret for verification, creating a scenario where an attacker can forge tokens using asymmetric keys that appear to be valid signatures.
This vulnerability directly maps to CWE-347: Improper Verification of Cryptographic Signature and CWE-295: Improper Certificate Validation, as it allows attackers to bypass the cryptographic integrity checks that should protect against forged authentication assertions. The flaw enables a complete bypass of OpenID Connect authentication mechanisms, allowing attackers to impersonate any user within the system.
The operational impact is severe for any relying party using this library, as it completely undermines the security model designed to protect user identities and access control. An attacker can create tokens with arbitrary claims including sub (subject) fields that identify them as any legitimate user, effectively granting unauthorized access to protected resources. This vulnerability affects all systems that rely on OIDC::Lite for ID token verification without explicitly pinning algorithms during the verification process.
The recommended mitigation involves ensuring that algorithms are explicitly pinned during token verification rather than allowing them to be derived from untrusted token headers. Systems should implement proper algorithm validation by setting $self->alg to a known safe value before calling verify, or by using explicit algorithm parameters when invoking the verification method. Additionally, organizations should update to patched versions of OIDC::Lite if available, or implement alternative authentication libraries that properly handle JWT algorithm validation.
The vulnerability demonstrates weaknesses in the ATT&CK framework's privilege escalation techniques, specifically targeting authentication bypass mechanisms through cryptographic manipulation. This flaw allows attackers to move laterally within systems by assuming identities of legitimate users, potentially escalating privileges and accessing sensitive resources without proper authorization. Security teams should review all applications using this library and implement immediate workarounds while planning for proper updates or replacements of vulnerable components.
This issue highlights the critical importance of proper cryptographic protocol implementation and the dangers of trusting token-provided parameters in security-critical contexts. The flaw serves as a reminder that even well-established authentication protocols can be compromised by subtle implementation errors that bypass fundamental security assumptions built into the cryptographic design. Organizations should perform thorough audits of their authentication systems to identify similar patterns where untrusted input directly controls critical security parameters.