EEF-CVE-2026-91187
Improper Verification of Cryptographic Signature in dashbit nimble_zta Cloudflare strategy
Quick fix
EEF-CVE-2026-91187 — nimble_zta: upgrade to the fixed version with the command below.
mix deps.update nimble_ztaDetails
## 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.
Are you affected?
Enter the version of the package you're using.
Affected packages
References
- https://github.com/dashbitco/nimble_zta/security/advisories/GHSA-rj24-g8cc-g7g2[ADVISORY]
- https://cna.erlef.org/cves/CVE-2026-91187.html[WEB]
- https://github.com/dashbitco/nimble_zta/commit/bc004b70985ae5763901baab3a4e204047899768[WEB]
- https://github.com/dashbitco/nimble_zta/commit/6458fd18a5ba41166d4973214c519e98fe05b72d[FIX]
- https://hex.pm/packages/nimble_zta[PACKAGE]