CVE-2026-119084 in Amazon Redshift JDBC Driver
Summary
by MITRE • 11/03/2026
Unsafe reflection in the connection parameter and credentials profile handling of Amazon Redshift JDBC Driver before 2.3.0 might allow an actor who can influence the JDBC connection URL or the AWS credentials profile to execute arbitrary code in the application context, provided a suitable class is available on the application classpath.
To remediate this issue, users should upgrade to version 2.3.0 or later.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified involves an unsafe reflection mechanism within the Amazon Redshift JDBC Driver prior to version 2.3.0, specifically affecting how connection parameters and AWS credentials profiles are processed. This flaw stems from a failure to properly validate input before using it in reflective operations, which allows for arbitrary code execution under specific conditions. The core technical issue lies in the driver's ability to instantiate classes or invoke methods based on user-supplied data derived from the JDBC connection URL or configuration files containing AWS credentials profiles. When an attacker can influence these inputs, they may manipulate the reflection logic to load and execute malicious class definitions that are present on the application classpath. This type of vulnerability is a classic example of insecure deserialization or unsafe reflection, where trusted code performs untrusted operations without adequate safeguards against malicious payloads.
From a technical perspective, Java applications often rely on reflection for dynamic loading of classes based on configuration strings. In this scenario, if the JDBC driver parses parts of the connection URL or credentials profile and uses them to determine which class to instantiate via Class.forName() or similar reflective calls, an attacker can supply a crafted string that references a malicious class. If such a class exists in the application's classpath, typically introduced through dependencies or local deployment artifacts, the JVM will load it and execute its static initializers or constructors. This process bypasses normal security checks because reflection operates at a lower level than standard method calls, often ignoring access modifiers unless explicitly restricted by a SecurityManager. The impact is severe as it grants the attacker full control over the application context, potentially leading to remote code execution, data exfiltration, or complete system compromise depending on the privileges of the running process.
This vulnerability aligns with CWE-470, which describes use of externally-controlled input to select classes or code to execute, a subset of broader injection flaws. It also maps to MITRE ATT&CK technique T1203, Exploitation for Client Execution, where attackers leverage vulnerabilities in client-side software to run malicious code on the target system. The attack vector requires that the attacker has some level of influence over the JDBC connection parameters or the AWS credentials profile configuration used by the application. This could occur through SQL injection if the URL is constructed dynamically from user input, or via local file manipulation if the credentials profile path is configurable and accessible to unauthorized users. Additionally, the presence of a suitable malicious class on the classpath is a critical prerequisite, meaning that supply chain integrity and dependency management play a crucial role in mitigating this risk.
The operational impact of exploiting this vulnerability extends beyond immediate code execution. An attacker could use this access to steal sensitive data stored within the application's memory or database connections, modify transactional logic, or establish persistence mechanisms for future attacks. Since Amazon Redshift is often used for critical analytics and reporting involving sensitive business intelligence, compromising its JDBC driver can lead to significant financial and reputational damage. Furthermore, because JDBC drivers are foundational components in many Java-based enterprise applications, the compromise of this library could affect a wide range of downstream systems that rely on it for database connectivity. The lack of input validation means that even minor changes in connection strings or configuration files can trigger the vulnerability if they contain specially crafted payloads designed to exploit the reflection logic.
To remediate this issue and prevent similar vulnerabilities, organizations must upgrade the Amazon Redshift JDBC Driver to version 2.3.0 or later, where these unsafe reflection practices have been addressed through stricter input validation and potentially the removal of dangerous reflective capabilities in favor of safer alternatives. Beyond upgrading software, developers should implement defense-in-depth strategies such as restricting classpath access to only necessary libraries, thereby reducing the attack surface for potential malicious classes. Utilizing a Java SecurityManager with strict policies can also help mitigate risks by preventing unauthorized reflection or class loading operations. Additionally, input validation techniques should be applied rigorously to all JDBC connection parameters and configuration inputs, ensuring that they conform to expected formats and do not contain suspicious patterns indicative of exploitation attempts. Regular auditing of dependencies and monitoring for unusual reflective activity in application logs are recommended practices to detect potential abuse early.