Critical 9.2 CVSS RCE Found in Amazon Redshift JDBC Driver

Security teams are being urged to move quickly following the disclosure of a critical Remote Code Execution (RCE) vulnerability found within the Amazon Redshift JDBC Driver. The flaw, tracked as CVE-2026-8178, carries a CVSSv4 score of 9.2, signaling a high risk for organizations utilizing this Type 4 driver for database connectivity.

The vulnerability strikes at the heart of how the driver handles standard JDBC application program interfaces (APIs). If left unpatched, it could allow an attacker to hijack the application’s execution environment.

The core of the issue lies in “Unsafe Class Loading.” In versions of the driver prior to 2.2.2, the software fails to properly sanitize certain connection URL parameters.

As the security advisory explains, “An issue exists in versions prior to 2.2.2 where the driver could load arbitrary classes when processing certain connection URL parameters, potentially allowing code execution in the application context.”

Essentially, if an actor can influence the JDBC connection string, they can trick the driver into executing code from classes already present on the application’s classpath. Because this execution happens in the context of the application’s Java Virtual Machine (JVM) process, the attacker effectively inherits the app’s identity and permissions.

Because the driver is often used to connect sensitive business intelligence tools and backend services to data warehouses, an attacker could achieve complete system compromise.

According to the advisory, “Successful exploitation could allow the actor to read sensitive data, modify application state, or disrupt service availability with the privileges of the application process.”

This means that everything from proprietary trade secrets to user databases could be exposed or deleted by an unauthenticated remote actor who gains a foothold through this driver flaw.

AWS has confirmed that the issue is fully addressed in Amazon Redshift JDBC Driver version 2.2.2.

AWS also recommends “ensuring any forked or derivative code is patched to incorporate the new fixes” to prevent the vulnerability from persisting in custom-built tools.