SQL Injection Through Unsupported Simple Query Mode in AWS Amazon JDBC Driver for Redshift

The Amazon JDBC Driver for Redshift is a Type 4 JDBC driver that provides database connectivity through the standard JDBC application program interfaces (APIs) available in the Java Platform, Enterprise Editions. Prior to version 2.1.0.28, SQL injection is possible when using the non-default connection property preferQueryMode=simple in combination with application code which has a vulnerable SQL that negates a parameter value. There is no vulnerability in the driver when using the default, extended query mode. Note that preferQueryMode is not a supported parameter in Redshift JDBC driver, and is inherited code from Postgres JDBC driver. Users who do not override default settings to utilize this unsupported query mode are not affected. This issue is patched in driver version 2.1.0.28. As a workaround, do not use the connection property preferQueryMode=simple. (NOTE: Those who do not explicitly specify a query mode use the default of extended query mode and are not affected by this issue.)

• The normalized record identifies AWS Amazon Redshift JDBC Driver versions < 2.1.0.28 as affected.
• The vendor advisory identifies Maven package com.amazon.redshift:redshift-jdbc42 versions <= 2.1.0.26 as affected and identifies 2.1.0.28 as patched.
• The vendor changelog states that 2.1.0.27 was published to Maven in error and is not recommended for use. Its separate vulnerability status is not independently established by the available evidence, so it should not be treated as a validated remediation.
• Later or parallel release branches should not be assumed safe without checking their corresponding vendor advisory or release information.

AWS Amazon JDBC Driver for Redshift is a Type 4 JDBC driver for Java applications. The weakness is CWE-89 and occurs while the driver serializes parameter values into SQL when the non-default simple query mode is used.

The related line-comment mechanism has the following high-level conditions:

1. The application explicitly sets the connection property preferQueryMode=simple.
2. The SQL statement contains a numeric placeholder immediately after a minus sign, followed by a string placeholder on the same line, and both values are user controlled.
3. In simple query mode, the driver inlines parameter values into the SQL statement instead of sending them separately.
4. A negative numeric value can form --, causing the rest of the line to be parsed as an SQL line comment. If the following string parameter contains a newline, its content can enter the SQL statement without the intended escaping.

The result can be SQL injection and execution of unintended statements. The default extended query mode sends parameters separately and is not affected according to the vendor advisory. The record does not identify the exact Redshift driver functions involved or the database privileges granted to a particular application connection.

The issue can be reached remotely through an application using the driver, provided that the application allows attacker-controlled input to reach a vulnerable SQL statement and has explicitly enabled preferQueryMode=simple. The supplied metrics describe exploitation as requiring no privileges or user interaction at the vulnerability layer, but practical reachability still depends on the application's input flow and the database account's permissions.

The supplied record does not identify a public exploit and does not establish whether the issue has been exploited in practice. No specific campaign, victim, or breach is named.

The flaw can alter the syntax of executed SQL even when the application uses prepared statements, but only when the driver operates in simple query mode. The technical consequence can extend from query construction in the driver to database resources accessible to the application's connection account.

If that account has sufficient permissions, possible effects include loss of confidentiality through data reads, loss of integrity through data modification or deletion, and loss of availability through disruptive or resource-intensive database operations. These are possible consequences, not evidence that a particular system was compromised. Not enabling preferQueryMode=simple, or using the default extended query mode, removes the exploitation condition described by the vendor.

An attacker may supply values to a vulnerable application statement and cause the database to parse SQL different from what the application intended. Depending on the database identity's permissions and the statement context, possible consequences include unauthorized reads, data modification, or disruptive database operations.

The record does not establish that any data was accessed, changed, or lost, and it does not name a victim or campaign. Exposure is narrower than a generic SQL injection finding because both explicit unsupported simple mode and vulnerable SQL construction are required.

1. Upgrade com.amazon.redshift:redshift-jdbc42 to exactly 2.1.0.28, which the vendor advisory identifies as patched. Verify the artifact actually loaded by each service after deployment.
2. If an upgrade cannot be completed immediately, remove preferQueryMode=simple from JDBC URLs, connection properties, connection pools, and environment-specific configuration. Leaving the query mode unspecified uses the default extended query mode according to the advisory.
3. Do not use 2.1.0.27, because the vendor changelog states that it was published to Maven in error and is not recommended for use.
4. Review externally influenced prepared statements, especially statements with a negated numeric value followed by a string parameter. Correct application logic that creates the vulnerable SQL pattern and limit the database identity to the minimum required permissions.
5. For release branches outside the boundaries listed above, verify support and patch status separately with the vendor before closing the remediation task.

1. Inventory Java applications and Maven dependencies using com.amazon.redshift:redshift-jdbc42; check the artifact actually loaded at runtime, not only source declarations or lockfiles.
2. Review JDBC URLs, connection pools, environment variables, and secrets for preferQueryMode=simple. Omitting the query mode uses the default extended query mode according to the advisory.
3. Search for prepared statements with a minus sign immediately before a numeric placeholder and a later string placeholder on the same line, where both values can be controlled externally. Prioritize paths that allow a newline in the string value.
4. Review Redshift audit and query logs for unexpected statement structures, conditions truncated by comments, or read, modification, and deletion operations inconsistent with application behavior. This is precautionary monitoring, not a vendor-confirmed indicator.
5. After remediation, recheck the dependency and runtime configuration for every service. Absence of suspicious log activity does not prove that a system is safe.