CVE-2026-93684

Incorrect implementation of JWT/OAuth authentication in Impala executors in Apache Impala versions up to and including 4.5.2 allows attackers to access resources served by the executor's webserver when that webserver is configured to accept JWT/OAuth tokens. Bearer token (JWT) signatures are not validated, resulting in the webserver accepting any valid JWT.

The Bearer token signature is not verified in the last step of SAML2 authentication for Impala's hs2-http interface, allowing alteration of the username and impersonation of another user. This affects Apache Impala versions >= 4.0.0.

In Apache Impala versions 2.7.0 to 2.8.0, a vulnerability was identified that allows a malicious process to impersonate an Impala daemon. This can lead to skipping authentication checks when Kerberos is enabled but TLS is not used.

Path traversal of 'trusted_jar_paths' in Impala 4.5.2 allows an attacker-controlled JAR to be loaded via a relative path where the prefix matches a path specified in 'trusted_jar_paths'. The attack requires 'trusted_jar_paths' to have a non-empty value configured by the Impala admin.

Insufficient authorization of Data Source tables in Impala 2.7-4.5 allows a client with privileges to upload a file to remote storage and create a table to execute arbitrary Java code. Users are recommended to upgrade to version 4.5.2.

Server side request forgery in Apache Impala versions 4.4.x and 4.5.x. Authenticated Impala users with permissions to execute the ai_generate_text() function can exfiltrate secrets provided by the credential providers configured in the hadoop.security.credential.provider.path property of core-site.xml. The secret's key must be known to the user.

Specifying tblproperties('avro.schema.url'=' http://...' ) or with a 'file:///' URI on a table in Impala 2.0.0 to 4.5.1 on all platforms allows an attacker to trigger a GET request to internal endpoints they may not have access to but that Impala does, and the response may be exposed via parsing error messages.