CVE-2026-91187 in nimble_zta
Summary
by MITRE • 09/24/2026
Improper Verification of Cryptographic Signature vulnerability in dashbit nimble_zta allows an unauthenticated remote attacker to authenticate as an arbitrary Cloudflare service token. Applications using the Cloudflare Zero Trust authentication strategy are affected.
verify_token/2 in lib/nimble_zta/cloudflare.ex matches the result of JOSE.JWT.verify/2 against {_, token, _s}, which discards the boolean verification result and returns the decoded token after a failed signature check. The attacker sends a forged JWT in the cf-access-jwt-assertion header, carrying the expected iss claim and the seven service token claims. verify_iss/2 reads the iss claim from the forged token, so it rejects nothing, and the service token path then returns those claims as the authenticated identity.
This issue affects nimble_zta: from 0.1.2 before 0.1.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in the dashbit nimble_zta library represents a critical failure in cryptographic signature verification, specifically within the Cloudflare Zero Trust authentication integration. This flaw allows an unauthenticated remote attacker to bypass access controls and authenticate as any arbitrary service token associated with Cloudflare services. The core of the issue lies in the verify_token/2 function located in lib/nimble_zta/cloudflare.ex, which is responsible for validating JSON Web Tokens used by applications employing the Cloudflare Zero Trust authentication strategy. When a client presents a JWT via the cf-access-jwt-assertion header, this function invokes JOSE.JWT.verify/2 to check the token's signature against the expected public key or secret. However, instead of properly handling the boolean result returned by the verification process, which indicates whether the signature is valid or invalid, the code discards this critical information.
Instead of returning an error or nil upon a failed signature check, the implementation proceeds to return the decoded token payload regardless of its authenticity. This logic error effectively nullifies the security guarantee provided by digital signatures. An attacker can exploit this by crafting a forged JWT that contains arbitrary claims but lacks a valid cryptographic signature. The JOSE library may still decode and parse the structure of the token even if the signature is invalid or missing, depending on how the wrapper function handles the return tuple from verify/2. By ignoring the verification status, nimble_zta treats this maliciously crafted token as legitimate, thereby granting the attacker access to resources protected by Cloudflare Zero Trust policies without possessing valid credentials.
The operational impact of this vulnerability is severe for any application relying on nimble_zta for authentication with Cloudflare services. Since the verify_iss/2 function subsequently reads the iss claim from the decoded payload and does not reject tokens based on signature validity, an attacker can manipulate claims to impersonate specific service identities. By including the expected issuer claim along with seven other service token claims in the forged JWT, the attacker satisfies all subsequent validation checks that rely solely on content rather than cryptographic proof of origin. This allows for unauthorized access to sensitive APIs, data exfiltration, and potential lateral movement within environments where Cloudflare Zero Trust is used as a primary authentication mechanism. The ability to authenticate as an arbitrary service token undermines the integrity of the entire identity management system, potentially leading to full compromise of dependent applications.
This vulnerability aligns with CWE-347, which describes Improper Verification of Cryptographic Signature, and maps directly to MITRE ATT&CK technique T1621, Multi-Factor Authentication Bypassing via Token Manipulation or Forgery in the context of cloud-based identity providers. The flaw stems from a common programming mistake where developers assume that decoding a token implies it is valid, failing to distinguish between structural validity and cryptographic authenticity. To mitigate this risk, organizations using nimble_zta must immediately upgrade to version 0.1.3 or later, which corrects the logic in verify_token/2 to properly check and enforce the boolean result from JOSE.JWT.verify/2. Until an update is applied, administrators should consider implementing additional validation layers at the application level or network perimeter that explicitly validate JWT signatures using independent libraries before processing any authentication requests. Regular security audits of cryptographic implementations are essential to prevent similar oversights in future development cycles.