Summary
- CVE-2026-119084 affects Amazon Redshift JDBC driver versions earlier than 2.3.0.
- Manipulated connection URL parameters or AWS credentials profile fields can trigger unsafe Java class loading.
- The vulnerability affects client applications using the driver, rather than demonstrating a compromise of Amazon Redshift itself.
Applications connecting to Amazon Web Services Redshift databases could be exposed to code execution through manipulated connection settings, following the discovery of a vulnerability in the service’s Java database driver.
AWS disclosed CVE-2026-119084 on 3 November, identifying unsafe Java class loading in Amazon Redshift JDBC driver versions earlier than 2.3.0.
The flaw could allow an attacker who influences a database connection URL or AWS credentials profile to trigger the execution of arbitrary classes within the affected application’s process.
AWS has released driver version 2.3.0 to correct the issue and recommends upgrading affected installations. The advisory does not identify confirmed exploitation in the wild.
Connection configuration becomes an execution path
Java Database Connectivity, or JDBC, is a standard interface used by Java applications to communicate with database services.
The Amazon Redshift JDBC driver implements that interface for connections to Redshift, AWS’s cloud data warehousing platform.
Applications use connection parameters to identify the database endpoint, establish authentication, and configure other aspects of the connection.
Those parameters are normally treated as configuration information rather than instructions capable of influencing the application’s execution.
However, Java software can use class-loading mechanisms to construct objects and initialise functionality dynamically. Where untrusted configuration values influence those mechanisms without appropriate restrictions, the distinction between configuration and executable behaviour can break down.
AWS says the vulnerable Redshift driver could load and execute arbitrary classes when processing certain JDBC connection URL parameters or AWS credentials profile fields.
An attacker able to modify the relevant values could therefore potentially cause code to run in the context of the application using the driver.
The resulting permissions would depend on that application’s operating environment. A process with access to configuration files, credentials, or connected services may present different consequences from an isolated application running with restricted permissions.
The advisory does not establish that every JDBC connection is vulnerable to exploitation, nor that an attacker can reach Redshift databases without authentication.
Its stated prerequisite is the ability to influence connection parameters or credentials profile information under conditions where unsafe class loading can occur.
Client-side security creates a separate dependency
Redshift is widely used for analytics, reporting, and data warehousing, often through applications that gather information from multiple sources.
Those environments can include reporting tools, data integration services, automated processing jobs, and internal applications that maintain database connections on behalf of users.
Some applications construct their connection settings entirely from trusted internal configuration. Others allow users, administrators, or connected services to supply destination information and connection properties.
The latter arrangements create a more relevant exposure where untrusted values can reach the affected driver.
Although the flaw concerns a Redshift connector, the vulnerable code runs within the client application rather than the underlying managed database service.
That distinction changes the remediation process. Updating Redshift itself does not necessarily update the JDBC library packaged inside an application or supplied by a third-party software vendor.
Organisations may need to identify the driver across deployed Java services, application dependencies, build files, and commercial products that provide Redshift connectivity.
AWS recommends upgrading to the latest driver version and checking that modified or derivative implementations incorporate the correction.
Where an immediate upgrade is not possible, it advises organisations to review the construction of JDBC connection URLs and AWS credentials profiles.
Untrusted input should not be used directly to build those configurations. Where externally supplied settings are necessary, AWS recommends validating them against an allowlist of expected parameters and values.
A further class-loading vulnerability
The disclosure follows an earlier Redshift JDBC driver vulnerability, CVE-2026-8178, which AWS addressed in May.
That earlier issue also involved unsafe class loading through connection parameters, but affected driver versions earlier than 2.2.2.
The new advisory identifies an additional vulnerability and extends the relevant processing conditions to AWS credentials profile fields, with version 2.3.0 providing the latest correction.
Consequently, an application updated to address the May issue may still require a further driver upgrade.
The repeated disclosures demonstrate the importance of treating application connectors as part of the software security boundary, rather than assuming database access controls address every risk associated with a database connection.
AWS has credited the researchers who participated in the coordinated disclosure process and published the corrected driver through its normal distribution channels, including Maven Central.
