SECURITYCRITICALCVE-2026-97720

CVE-2026-97720: Apache Impala JWT/OAuth Authentication Bypass

Apache Impala executor webservers accept any valid JWT without checking its signature, letting attackers bypass JWT/OAuth auth entirely.

Dylan H.

Security Team

October 8, 2026
3 min read
CVE-2026-97720: Apache Impala JWT/OAuth Authentication Bypass

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • Apache Impala 4.1.0 - 4.5.2

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

AttributeValue
CVE IDCVE-2026-97720
CWECWE-303: Incorrect Implementation of Authentication Algorithm
Affected ComponentImpala executor webserver
PreconditionExecutor webserver configured for JWT/OAuth auth
Root CauseBearer token (JWT) signatures are not verified
Affected VersionsImpala 4.1.0 – 4.5.2
Patched VersionImpala 4.5.3
ReservedSeptember 24, 2026
PublishedOctober 7, 2026
CreditAndrew 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

  1. Upgrade to Impala 4.5.3, which fixes the signature validation gap, as soon as your deployment pipeline allows
  2. Until patched, disable JWT/OAuth authentication on executor webservers if operationally acceptable, and rely on network-level restrictions (firewall rules, internal-only binding) instead
  3. Audit executor webserver access logs for requests bearing JWTs that would not survive signature verification, which may indicate prior exploitation attempts
  4. 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

Sources