Amazon Redshift JDBC Driver CVE-2026-119084: unsafe class loading fixed in 2.3.0

What happened

AWS published security bulletin 2026-168-AWS on 3 November 2026 for CVE-2026-119084 (also GHSA-qrph-v96m-w2mv) in the Amazon Redshift JDBC Driver. The AWS bulletin says that in some conditions the driver can load and run arbitrary classes. This happens when it handles JDBC connection URL parameters or AWS credentials profile fields.

• Affected: Amazon Redshift JDBC Driver versions before 2.3.0.
• Fixed: version 2.3.0. AWS recommends moving to the latest release, which it distributes through the Redshift documentation and Maven Central. The v2.3.0 release on GitHub is described as the release of driver version 2.3.0.
• Impact per AWS: someone able to influence the connection URL or credentials profile could potentially run code in the application's context.
• Precondition: the NVD and OSV descriptions add that code execution requires a suitable class to be present on the application classpath.
• Weakness: the CVE record classifies it as CWE-470, unsafe reflection.
• Severity: AWS labels the bulletin "Important (requires attention)". NVD shows a CVSS base score of 9.2, with its own analysis still pending. The CVE record also carries a CVSS v3.1 score of 8.1 (High, attack complexity High) alongside the v4.0 score of 9.2 (Critical, attack requirements Present).
• Forks: AWS explicitly says forked or derivative code must also be patched.

Why it matters

The title says remote code execution, and a 9.2 score will put this at the top of many scanner dashboards. The text underneath is narrower, because two conditions must both hold.

1. An attacker must influence the connection URL or the credentials profile. In our assessment, this path is not reachable from untrusted input where both the connection string and the credentials profile are fixed operator configuration. Teams should confirm that both inputs are fixed, not just the URL.
2. A suitable class must be on the classpath. Unsafe reflection needs a usable class to instantiate. Java applications with large dependency trees probably make that condition easier to meet. The evidence does not say which classes qualify.

Exposure rises sharply for software that lets someone other than the operator shape the connection. That group includes:

• BI and reporting tools where users add their own data sources
• ETL and data-integration platforms
• SaaS products that connect to a customer's Redshift cluster
• internal "bring your own warehouse" features
• services that assemble JDBC URLs from tenant records or a shared config store

For those systems, the attacker-controlled input is the product feature itself.

The second group is easy to miss: anything that embeds the driver. Desktop SQL clients, data tools and vendor appliances often bundle or shade JDBC drivers inside their own artifacts. A Maven or Gradle upgrade in your own repositories does not touch those copies. This is why the AWS instruction on forked or derivative code matters.

Engineering assessment

Our assessment: this is a high-priority fix for a minority of deployments and a routine dependency upgrade for everyone else.

Both CVSS vectors in the CVE record encode a precondition: v3.1 rates attack complexity High, and v4.0 marks attack requirements Present. Both still score the issue as network-reachable with no privileges required. The precondition is therefore what decides real exposure: who can influence the connection input, and what is on the classpath.

Where the connection URL is operator-controlled and held in a secrets manager or deployment config, an attacker who can rewrite it usually already has significant access. The vulnerability then turns configuration-write access into code execution in the JVM. That is a real escalation, especially where config stores are shared more widely than application hosts. It is not an unauthenticated perimeter breach.

Where tenants or users supply connection details, treat this as urgent. Multi-tenant data platforms are the obvious case. Code execution in the application context there could mean access to other tenants' credentials and data. That matters for UK, EU and Gulf organisations under data-protection and sector rules in healthcare and government.

The classpath precondition offers little comfort. Teams cannot easily reason about it for a typical Spring, Hadoop or BI deployment, and the evidence does not say what a "suitable class" looks like. Plan as if the condition can be met.

Upgrade risk is hard to size. The release page supplied gives no changelog, so the scope of change from older versions is unknown. Given the CWE-470 classification, the fix likely restricts how classes are selected from connection input, but the evidence does not describe the change. Teams that pass custom plugin or provider classes through connection properties should regression-test authentication and connection setup before rolling out widely.

This does not change earlier recommendations. It reinforces one that applies to every JDBC driver: never let untrusted input reach a connection string unvalidated.

Is this you?

• You run any Amazon Redshift JDBC Driver version below 2.3.0, directly or transitively.
• Users, tenants or customers can enter or edit Redshift connection details (host, URL, properties) in your product or internal tooling.
• Your code builds JDBC URLs by concatenating values from requests, tenant records, feature flags or a shared config store.
• People or systems other than the service owner can edit the credentials profiles the driver uses.
• You ship or operate BI, ETL, notebook or SQL-client tools that bundle a Redshift driver.
• You maintain a fork, shaded copy or vendored source of the driver.

If only the first item applies and connection details and credentials profiles are fixed operator configuration, your exposure is low. You should still upgrade.

What to do

1. Inventory first. Find every copy of the driver, not just declared dependencies:
   • mvn dependency:tree | grep -i redshift
   • gradle dependencies | grep -i redshift
   • find / -iname "*redshift*.jar" 2>/dev/null
   • For fat or shaded jars: unzip -l your-app.jar | grep -i redshift
   • Check container images and SBOMs for the same artifact.
2. Upgrade to 2.3.0 or later now where tenants or users influence connection details. For services with fixed, operator-owned configuration, upgrade in your next normal release cycle, measured in days rather than weeks.
3. Patch forks and vendored copies. AWS states that derivative code must incorporate the fix. If you maintain a fork, rebase onto 2.3.0.
4. Chase vendors. For third-party BI, ETL and SQL tools that bundle the driver, ask which driver version they ship and when they will include 2.3.0. Until then, restrict who can create or edit Redshift data sources in those tools.
5. If you cannot upgrade immediately, follow the AWS workaround:
   • Review how connection URLs and credentials profiles are built.
   • Do not build them from untrusted input, or validate external values against an allowlist of expected parameters and values.
6. Test before broad rollout. Cover IAM and federated authentication, any custom provider classes set through connection properties, and connection pooling behaviour.
7. Not vendor guidance: tighten write access to the config stores and secrets that hold Redshift connection strings and credentials profiles, and alert on changes to them. Where users supply connection details, accept structured fields (host, port, database) rather than raw JDBC URLs, and build the URL server-side.

What we don't know yet

• Trigger surface: which connection URL parameters and credentials profile fields cause the class loading. The bulletin does not list them.
• How the fix works: the bulletin and release page do not describe the code change.
• Gadget availability: which classes count as "suitable", and how common they are in typical application, BI and ETL classpaths.
• Shared credentials files: whether the mention of credentials profiles implies exposure through shared AWS config or credentials files. The evidence does not say.
• Exploitation status: none of the supplied sources says whether the issue has been exploited.
• Release timing: the GitHub release page shows 15 Oct with no year, ahead of the 3 November bulletin. It is unclear whether the fixed build was public before the advisory.
• Downstream products: which popular products bundle or shade the driver, and when they will ship 2.3.0.
• Final scoring: NVD analysis is still pending.

The desk will watch for NVD's assessment, any expansion of the GitHub advisory, and statements from vendors whose tools embed the driver.

Sources

• aws.amazon.com
• aws.amazon.com
• github.com
• github.com
• OSV
• NVD