EEF-CVE-2026-91187

Source
https://cna.erlef.org/osv/EEF-CVE-2026-91187.html
Import Source
https://cna.erlef.org/osv/EEF-CVE-2026-91187.json
JSON Data
https://api.osv.dev/v1/vulns/EEF-CVE-2026-91187
Aliases
  • CVE-2026-91187
  • GHSA-rj24-g8cc-g7g2
Published
2026-09-24T13:20:52Z
Modified
2026-09-24T13:41:01Z
Severity
  • 9.3 (Critical) CVSS_V4 - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N CVSS Calculator
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.

Database specific
{
    "capec_ids":  [
        "CAPEC-475"
    ],
    "cpe_ids":  [
        "cpe:2.3:a:dashbit:nimble_zta:*:*:*:*:*:*:*:*"
    ],
    "cwe_ids":  [
        "CWE-347"
    ]
}
References
Credits
    • Kazlu - FINDER
    • José Valim / Dashbit - REMEDIATION_DEVELOPER
    • Jonatan Männchen / EEF - COORDINATOR

Affected packages

Hex / nimble_zta

Package

Name
nimble_zta
Purl
pkg:hex/nimble_zta

Affected ranges

Type
SEMVER
Events
Introduced
0.1.2
Fixed
0.1.3

Affected versions

0.*
0.1.2

Database specific

source
"https://cna.erlef.org/osv/EEF-CVE-2026-91187.json"

Git / github.com/dashbitco/nimble_zta

Affected ranges

Type
GIT
Repo
https://github.com/dashbitco/nimble_zta
Events

Affected versions

v0.*
v0.1.2

Database specific

source
"https://cna.erlef.org/osv/EEF-CVE-2026-91187.json"