Amazon Redshift JDBC Driver EUVD-2026-116383

Exploitation requires that the attacker can influence the JDBC connection URL parameters or the AWS credentials profile fields consumed by the Redshift JDBC driver before version 2.3.0, AND that a suitable exploitable class is already present on the application's classpath for the driver to load and execute. This is not a flaw against a default standalone deployment of the driver itself - it is reachable only where an application passes externally controllable values into connection-string or credentials-profile construction. Limiting factors: the dependency on an available classpath gadget class (reflected as AT:P in CVSS 4.0 / AC:H in CVSS 3.1), and the need for an attack surface that lets untrusted input reach the connection URL or credentials profile; applications that build these only from trusted, static configuration are not realistically exploitable. The vendor workaround is to not build URLs/credentials profiles from untrusted input or to allowlist externally supplied parameter values; upgrading to 2.3.0 is the complete fix.

This is a genuinely high-priority issue, but its real-world risk is gated by a specific precondition rather than being broadly remote-unauthenticated. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.2) and the GHSA CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, score 8.1) agree on network vector, no privileges, no user interaction, and full confidentiality/integrity/availability impact - i.e. remote code execution. The two vectors differ on complexity: the 4.0 assessment uses AC:L with AT:P (a present attack requirement), while the 3.1 assessment folds that same gating into AC:H; both are capturing the same real constraint, that a suitable loadable/gadget class must exist on the application classpath and the attacker must be able to influence the JDBC connection URL or AWS credentials profile. The vuln.today priority is act_now and a vendor patch exists, so this should be treated as urgent. However, no EPSS score, no CISA KEV listing, and no confirmed public exploit code are present in the input - so there is no evidence of active mass exploitation, and the practical risk depends heavily on whether an application exposes connection-string or credentials-profile construction to untrusted input. CWE-470 (unsafe reflection) is consistent with the described class-loading mechanism.

An application builds a Redshift JDBC connection URL or AWS credentials profile using values that an attacker can influence (for example a multi-tenant data tool or admin UI that accepts connection parameters). The attacker supplies a crafted parameter that causes the pre-2.3.0 driver to reflectively load and instantiate a class already present on the application classpath, executing code inside the application's JVM. No public exploit code is identified in the input, though researchers (4ra1n, pyn3rd, unam4) disclosed the issue via coordinated disclosure.