Vulnerability EEF-CVE-2026-91187

Unknown
UNKNOWN RISK
Vulnerabilities without an assigned CVSS score. Severity is not determinable from available data.
3 days ago
September 24, 2026 at 01:20 PM UTC
Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy
0.1.2
0.1.2

Summary

Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy

Details

Summary

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.

Proof of concept

  1. Build a JWT payload that carries the aud, common_name, exp, iat, iss, sub and type claims. Use the iss the application expects, set exp to a future timestamp, and set common_name to the service token to impersonate.
  2. Append any signature segment. The segment must be present, because JOSE.JWT.verify/2 needs three segments to parse the token. The signature does not need to verify against the Cloudflare keys.
  3. Send a request to the application with the forged JWT in the cf-access-jwt-assertion header.
  4. NimbleZTA.Cloudflare.authenticate/3 returns the claims of the forged token as the authenticated identity, with the strategy field set to service_token.

Impact

The attacker authenticates as an arbitrary Cloudflare service token without holding the Cloudflare signing key. The application receives the client_id and the claims of the forged token as the authenticated identity, so the attacker gets the access that the application grants to that service token.

Workarounds

Disable the Cloudflare authentication strategy.

To keep the user identity strategy available, reject the service token requests yourself. Examine each request before you call NimbleZTA.Cloudflare.authenticate/3, and reject it if its JWT carries the common_name claim and the type claim.

Configurations

The application must add NimbleZTA.Cloudflare to its supervision tree and authenticate requests through it.

Impacted packages

Timeline

Published
3 days ago
September 24, 2026 at 01:20 PM UTC
Fixed (0.1.3)
4 days ago
September 24, 2026 at 07:24 AM UTC
Last Modified
3 days ago
September 24, 2026 at 01:41 PM UTC