CVE-2026-65181: 
Apache Impala vulnerability analysis and mitigation

CVE-2026-65181 is a remote code execution vulnerability in Apache Impala caused by insufficient authorization of Data Source tables, allowing an authenticated attacker to execute arbitrary Java code. It affects Apache Impala versions 2.7.0 through 4.5.1 and was publicly disclosed on September 8, 2026, with a patch released in version 4.5.2. The vulnerability carries a CVSS v3.1 base score of 8.1 (High) (Apache Advisory, GitHub Advisory). The vulnerability was reported by zhaokaifei of ChinaTelecom (OSS-Sec).

The root cause is classified as CWE-913 (Improper Control of Dynamically-Managed Code Resources), where Impala fails to properly restrict the creation and use of External Data Source tables (GitHub Advisory). An attacker who holds privileges to upload files to remote storage and create tables can craft a malicious Java class, upload it as a JAR to remote storage, and register it as an External Data Source, causing Impala to load and execute the arbitrary Java code upon table creation or query. The attack is network-based, requires low privileges, no user interaction, and low attack complexity, making it straightforward to exploit for any authenticated user with the relevant permissions (Apache Advisory, OSS-Sec).

Successful exploitation allows an authenticated attacker to execute arbitrary Java code on the Impala server, resulting in high impact to both confidentiality and integrity of the affected system. An attacker could access sensitive data stored or processed by Impala, modify data, or use the compromised Impala node as a pivot point for lateral movement within the data platform environment. Availability is not directly impacted according to the CVSS scoring, but the ability to run arbitrary code on the server represents a significant risk to the overall data infrastructure (GitHub Advisory, OSS-Sec).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Apache Advisory). The NVD SSVC assessment indicates exploitation is currently "none" and the attack is not automatable due to the requirement for low-level authenticated privileges (GitHub Advisory). The EPSS score is approximately 0.43–0.56%, placing it in the 45th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify Apache Impala instances running versions 2.7.0 through 4.5.1 accessible over the network. Confirm the target version via Impala's web UI (default port 25000) or by querying SELECT version().
2. Obtain required privileges: Acquire or compromise credentials for an Impala user account that has privileges to upload files to remote storage (e.g., HDFS or S3) and to execute CREATE TABLE statements with external data sources.
3. Craft malicious JAR: Develop a Java class implementing the Impala External Data Source API interface that contains a malicious payload (e.g., a reverse shell or command execution routine). Compile and package it as a JAR file.
4. Upload JAR to remote storage: Use authorized credentials to upload the malicious JAR to a remote storage location accessible by the Impala cluster (e.g., hdfs dfs -put malicious.jar /user/attacker/).
5. Register malicious data source: Execute a CREATE DATA SOURCE statement in Impala pointing to the uploaded JAR and specifying the malicious class as the implementation (e.g., CREATE DATA SOURCE evil LOCATION 'hdfs:///user/attacker/malicious.jar' CLASS 'com.attacker.MaliciousDS' API_VERSION 'V1').
6. Trigger code execution: Create or query a table using the registered data source (CREATE TABLE t PRODUCED BY DATA SOURCE evil(...)), causing Impala to load and instantiate the malicious Java class, executing the attacker's payload on the Impala server (OSS-Sec, GitHub Advisory).

• Network: Unexpected outbound connections from the Impala daemon process (e.g., impalad) to external or unusual IP addresses, potentially indicating a reverse shell or data exfiltration.
• File System: Presence of unexpected or newly uploaded JAR files in HDFS or other remote storage paths not associated with legitimate Impala workloads; unusual files in Impala's working directories.
• Logs: Impala audit logs showing CREATE DATA SOURCE or CREATE TABLE ... PRODUCED BY DATA SOURCE statements executed by non-administrative or unexpected user accounts; Impala daemon logs showing class loading events for unfamiliar Java classes.
• Process: Unusual child processes spawned by the impalad process (e.g., shell interpreters, network utilities like curl, wget, or nc); unexpected Java threads or class loader activity in Impala JVM heap dumps.

The primary remediation is to upgrade Apache Impala to version 4.5.2 or later, which addresses the insufficient authorization check for External Data Source tables (Apache Advisory, OSS-Sec). As interim workarounds, administrators should restrict privileges for uploading files to remote storage and creating External Data Source tables to only highly trusted users, and audit existing grants to revoke unnecessary permissions. Additionally, implementing network segmentation to limit access to Impala services reduces the attack surface for authenticated but potentially compromised accounts.

The vulnerability was covered by several security news aggregators and vulnerability tracking services shortly after disclosure, including SecurityOnline and BulwarkBlack, which noted the RCE risk in the context of zero-trust data platforms (SecurityOnline, BulwarkBlack). The Apache security team issued the advisory promptly and credited the reporter, zhaokaifei of ChinaTelecom, for responsible disclosure (OSS-Sec). No significant social media controversy or major vendor statements beyond the official advisory have been observed.