Apache Impala CVE-2026-90466

Exploitation is only possible when the Impala admin has configured the startup flag 'trusted_jar_paths' with a non-empty value (a non-default condition) AND the attacker already has sufficient privileges to run the DDL statements CREATE DATA SOURCE and/or CREATE TABLE to upload a JAR to an arbitrary location in the same filesystem. The attacker must then supply a relative path whose prefix matches an existing trusted path; the traversal cannot override the URI schema, so the malicious JAR must reside on the same local/remote filesystem as the trusted path. Limiting factors: no trusted_jar_paths means no attack surface, the schema constraint confines the JAR location, and DDL execution requires authenticated/authorized database access rather than anonymous network access.

No CVSS vector, EPSS score, KEV listing, or public POC is present in any provided source (NVD/vendor/Jira all show CVSS N/A), so quantitative exploitation signals are entirely absent and the only severity anchor is Apache's qualitative rating of 'important'. Judged on the description alone, this is a conditional, privilege-and-configuration-dependent flaw rather than a drive-by: exploitation requires (a) an admin to have configured a non-empty 'trusted_jar_paths' and (b) an attacker who can already execute DDL (CREATE DATA SOURCE / CREATE TABLE) to stage a malicious JAR. Those preconditions sharply reduce the realistic attack surface compared with an unauthenticated RCE, but the payoff is high - arbitrary JAR loading means code execution in the Impala service context. Net assessment: a genuine but gated privilege-escalation/code-execution issue for Hadoop/big-data shops running the specific vulnerable build (4.5.2); patch promptly where trusted_jar_paths is in use, but it is not an internet-wide emergency. Key missing data (no EPSS, no CVSS, no KEV, no POC) means this ranking is inferred from the description and should be re-checked once NVD scores and any exploit code appear.

In an Impala 4.5.2 deployment where the admin has set a non-empty 'trusted_jar_paths', an authenticated user with DDL rights uploads a malicious JAR to an arbitrary location in the same filesystem using CREATE DATA SOURCE or CREATE TABLE, then references it with a relative path whose prefix matches a trusted path, bypassing the trusted-path check and loading attacker-controlled code into Impala. No public exploit identified at time of analysis, so a real attacker would have to weaponize the technique from the advisory themselves.