Impala Executor Webservers Accept Any Valid JWT
Apache has disclosed CVE-2026-97720, an authentication bypass in Apache Impala's executor webserver stemming from an incorrect implementation of JWT/OAuth authentication. When an Impala executor's webserver is configured to accept JWT or OAuth bearer tokens, it fails to validate the token's signature — meaning any syntactically valid JWT, including one an attacker crafts themselves, is accepted as legitimate authentication.
The flaw affects Impala 4.1.0 through 4.5.2 and is fixed in version 4.5.3. It was reported by Andrew Rukin of Arenadata.
Vulnerability Details
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-97720 |
| CWE | CWE-303: Incorrect Implementation of Authentication Algorithm |
| Affected Component | Impala executor webserver |
| Precondition | Executor webserver configured for JWT/OAuth auth |
| Root Cause | Bearer token (JWT) signatures are not verified |
| Affected Versions | Impala 4.1.0 – 4.5.2 |
| Patched Version | Impala 4.5.3 |
| Reserved | September 24, 2026 |
| Published | October 7, 2026 |
| Credit | Andrew Rukin (Arenadata) |
Third-party scoring sources list this issue at up to CVSS 9.1, reflecting the practical impact of a full authentication bypass, even though Apache's own advisory initially characterized the severity more conservatively. Treat any Impala deployment using JWT/OAuth-protected executor webservers as exposed until patched.
Why Signature Validation Matters Here
JWT/OAuth authentication is only as strong as the signature check behind it. A bearer token's claims — who the caller is, what role they hold — are meaningless if the server never confirms the token was actually issued (and signed) by a trusted authority. Apache Impala's executor webserver accepted any well-formed JWT, regardless of whether it had been signed correctly, effectively reducing "authenticated" access to "anyone who can construct a JWT-shaped string."
This matters specifically for the executor role in Impala's architecture — the components that serve resources (profiles, logs, diagnostic data) via their own embedded webserver, separate from the coordinator-facing interface. Organizations that enabled JWT/OAuth specifically to lock down executor webserver access were left with a bypassable control instead.
Remediation
- Upgrade to Impala 4.5.3, which fixes the signature validation gap, as soon as your deployment pipeline allows
- Until patched, disable JWT/OAuth authentication on executor webservers if operationally acceptable, and rely on network-level restrictions (firewall rules, internal-only binding) instead
- Audit executor webserver access logs for requests bearing JWTs that would not survive signature verification, which may indicate prior exploitation attempts
- Treat any Impala cluster with internet-exposed or broadly-reachable executor webservers as highest priority for the 4.5.3 upgrade, since the bypass requires no valid credentials at all