VDB
Sign up

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_zta

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.

Are you affected?

Enter the version of the package you're using.

Affected packages

Hex/nimble_zta
Introduced in: 0.1.2Fixed in: 0.1.3
Fixmix deps.update nimble_zta

References