CVE-2026-70410 in Calcite Avatica
Summary
by MITRE • 09/22/2026
Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in Apache Calcite Avatica. Plugin instantiation (via AvaticaUtils#instantiatePlugin and other methods) initializes arbitrary classes via unrestricted calls to Class.forName(String) which by default triggers initialization. This may lead to the execution of static initializer blocks in arbitrary classes present in the classpath. The instantiation APIs should initialize and instantiate only classes implementing the specified plugin interface passed as input in conjunction with the desired classname. At the moment of writing, there are no well-known or widely used classes with dangerous static initializer blocks so the severity is low.
This issue affects Apache Calcite Avatica: before 1.29.0.
Users are recommended to upgrade to version 1.29.0, which fixes the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Apache Calcite Avatica prior to version 1.29.0 represents a critical flaw in how plugin instances are created and managed within the application framework. This security defect is categorized under CWE-470, known as Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection'). The core technical issue lies in the implementation of methods such as AvaticaUtils#instantiatePlugin and related utility functions that rely on unrestricted calls to Class.forName(String). In Java, invoking this method with a class name not only loads the class into memory but also triggers its initialization phase. This initialization process includes the execution of static initializer blocks, which are code segments defined within a class that run automatically when the class is loaded. Because these methods do sufficiently validate or restrict the input to ensure it corresponds strictly to expected plugin interfaces, an attacker who can influence the classname parameter may force the application to load and initialize arbitrary classes present in the system's classpath.
The operational impact of this vulnerability stems from the potential execution of static initializer blocks within maliciously crafted or unexpectedly loaded classes. Static initializers are powerful constructs that can perform a wide range of operations, including opening network connections, reading sensitive files, modifying global state, or executing arbitrary code upon loading. If an attacker controls the input passed to these instantiation methods, they could potentially trigger side effects associated with any class available in the runtime environment. This mechanism effectively bypasses standard access control mechanisms because it leverages legitimate framework functionality for unintended purposes. Although the immediate severity is assessed as low due to the current absence of well-known or widely used classes containing dangerous static initializer blocks on typical classpaths, the underlying flaw remains a significant security risk. The lack of input validation means that if any such vulnerable class were introduced into the environment through dependencies or custom plugins, it could be exploited without further modification by an attacker.
From a threat modeling perspective, this vulnerability aligns with ATT&CK technique T1059, Command and Scripting Interpreter, specifically regarding dynamic code execution via reflection. It also relates to CWE-20, Improper Input Validation, as the system fails to adequately sanitize or verify that the provided class name adheres to a whitelist of allowed plugins or interfaces. The flaw allows for an indirect command injection scenario where the attacker does not inject code directly but rather selects which existing code paths are executed by manipulating reflection parameters. This type of vulnerability is particularly insidious because it operates within the bounds of normal application behavior, making detection through standard logging and monitoring more challenging compared to direct exploitation attempts.
To mitigate this risk, users must upgrade Apache Calcite Avatica to version 1.29.0 or later, where the instantiation APIs have been patched to enforce stricter validation. The fix ensures that only classes implementing the specified plugin interface are eligible for initialization, thereby preventing the loading of arbitrary unrelated classes. In environments where upgrading is not immediately feasible, administrators should implement strict classpath management to remove any potentially dangerous third-party libraries that might contain malicious static initializers. Additionally, deploying runtime application self-protection (RASP) solutions or Web Application Firewalls with deep reflection inspection capabilities can provide an additional layer of defense by monitoring and blocking suspicious Class.forName calls originating from untrusted sources. Regular security audits focusing on input validation in reflective operations are also recommended to identify similar patterns across the codebase before they can be exploited.