Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Search

EEF-CVE-2026-91187

CriticalCVSS 9.3 / 10
Published Sep 24, 2026·Last modified Sep 24, 2026
Affected Components(2)
dashbitco/nimble_zta
0.1.2
Hexnimble_zta
0.1.2 – 0.1.3
Description

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.

Upload your SBOM

Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.

Risk Scores
Base Score
9.3

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability.

Threat Intelligence
7.8

Exploitation activity has been observed. Apply available patches or mitigations urgently.

EPSS
0.30%

The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard