Unsafe reflection enables arbitrary code execution in AWS Amazon Redshift JDBC Driver

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.

• AWS Amazon Redshift JDBC Driver: affected from version 0 through versions less than 2.3.0; the record's default status is unaffected outside the explicitly listed affected range.
• Maven package com.amazon.redshift:redshift-jdbc42: the GitHub advisory identifies versions less than 2.3.0 as affected.
• Patched release: 2.3.0. The sources reviewed do not specify an additional release branch or parallel product boundary.

The affected component is the driver's JDBC connection URL parameter and AWS credentials profile handling, including the com.amazon.redshift:redshift-jdbc42 package. The driver uses externally influenced values in reflection or class-loading decisions without sufficiently restricting the selected class or code, matching CWE-470. When a suitable class is already available on the application classpath and an actor can influence the connection URL or credentials profile, the driver may load and execute that class in the application's JVM context. The supplied assessment classifies the path as network reachable, with no authentication or user interaction required; actual reachability depends on the deployment path that permits influence over those inputs. The exact parameter names, reflection call path, and class requirements beyond the presence of a suitable class remain unknown.

The supplied assessment describes network reachability with no required privileges and no user interaction. Exploitation nevertheless requires an actor to influence the JDBC connection URL or AWS credentials profile, together with a suitable class on the application classpath; the delivery path depends on the deployment. The record contains differing complexity assessments across scoring versions, so practical exploitability should not be inferred from one metric alone. The record does not confirm observed exploitation or the existence of a public exploit.

Arbitrary code execution occurs in the application context, with the effective privileges of the JVM process using the driver. This could cause loss of confidentiality, integrity, and availability for data or resources reachable by that process. The blast radius is likely to depend on the application account, secrets loaded into the process, and permitted network connections. The record does not establish a specific breach scenario or impact beyond the application's context.

Successful exploitation could provide arbitrary code execution with the privileges of the application process, potentially exposing or modifying data and resources available to that process and disrupting service. The practical blast radius depends on the JVM account, application secrets, system permissions, and network access available to the process. The flaw can turn a database connectivity library into a code-execution point inside applications that use it. The record does not identify a specific dataset, host, organisation, or breach that was affected.

1. Upgrade Amazon Redshift JDBC Driver to 2.3.0, including deployments using com.amazon.redshift:redshift-jdbc42, and verify the deployed runtime artifact.
2. If forked or derivative code is used, incorporate the corresponding fixes and rebuild the artifact.
3. Until the upgrade is complete, do not construct JDBC connection URLs or AWS credentials profiles from untrusted input. Where external values must be accepted, validate them against an allowlist of expected parameters and values.
4. Recheck every service that uses the driver, including services that package it in a shaded or fat JAR, because changing only the dependency declaration may not change the artifact actually running in production.

1. Inventory applications, containers, packages, and shaded or fat JARs containing Amazon Redshift JDBC Driver, and check the artifact running in production rather than only source dependency declarations.
2. For each deployment, trace whether untrusted or externally controlled data can influence the JDBC connection URL or AWS credentials profile fields.
3. Review forks and derivative code, along with configuration and dependency changes involving the driver, to verify that the fix is present in the deployed artifact.
4. Application or JVM telemetry can be used as a precaution to investigate unexpected class loading or code execution during connection initialization, but the record and reviewed advisories provide no specific log event or IOC.