CVE-2024-32888

What it actually does

This flaw is a conditional SQL injection issue in the Amazon Redshift JDBC Driver before version 2.1.0.28. It is only exposed when an application explicitly sets the unsupported connection property `preferQueryMode=simple` and the application constructs a vulnerable SQL statement that negates a parameter value. In that mode, the driver can fail to preserve intended parameterization semantics, allowing attacker-controlled input to alter the SQL statement sent to Amazon Redshift. Successful exploitation can allow unauthorized query manipulation, data disclosure, data modification, or destructive database operations depending on the database permissions of the application account. Applications using the default extended query mode are not affected.

Why it matters to the business

If exploitable in an application, this vulnerability can allow an unauthenticated remote attacker to manipulate database queries issued by the application, potentially exposing sensitive analytics data, corrupting business records, or disrupting reporting and data processing workflows. The CVSS score is critical, but real-world exposure is narrower because exploitation requires the non-default `preferQueryMode=simple` setting and vulnerable application SQL construction. It is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so prioritization should focus first on internet-facing or high-trust applications that use the Redshift JDBC driver with the affected connection option.

How an attack unfolds

An attacker first identifies an application endpoint that accepts input later used in a Redshift-backed query. The application must be using an affected Amazon Redshift JDBC Driver version and must explicitly enable the unsupported `preferQueryMode=simple` connection property. The attacker then supplies crafted input to a parameter that is used in application SQL involving a negated parameter value. Because the driver is operating in simple query mode, the intended separation between SQL structure and attacker-controlled data can break down in the vulnerable pattern. The resulting SQL sent to Redshift may include attacker-influenced logic rather than only the intended value. If the application database role has sufficient privileges, the attacker may read unauthorized data, alter query filters, modify records, run additional database operations, or cause query failures and availability impact. There are no known named threat actors or public exploitation campaigns associated with this issue based on the supplied data.

How to fix it

Upgrade the Amazon Redshift JDBC Driver to version 2.1.0.28 or later. For source-based consumers, ensure the driver includes the upstream fix commit `51af003d4be170042faef20dadbcf4f992e10d8a`. Remove the unsupported connection property `preferQueryMode=simple` from all Redshift JDBC connection strings and configuration files; the default extended query mode is not affected. Review application code for SQL patterns that negate parameter values and ensure all SQL uses safe parameter binding without string concatenation. Apply least-privilege permissions to Redshift application roles so that any query manipulation has limited blast radius. If immediate upgrade is not possible, mitigation should prioritize removing `preferQueryMode=simple`, redeploying affected services, and rotating or constraining credentials used by exposed applications.

How to confirm the fix worked

Confirm dependency inventories, build manifests, container images, and deployed artifacts use Amazon Redshift JDBC Driver version 2.1.0.28 or later. Search application configuration, environment variables, secrets templates, deployment manifests, and connection-string builders for `preferQueryMode=simple`; affected deployments should not contain this setting. Validate runtime behavior by checking effective JDBC URLs or startup logs where connection properties are emitted. Review application source for negated parameter SQL patterns and verify that prepared statements are still used safely. In Redshift, review recent query history and audit logs for suspicious SQL fragments, unexpected changes to query predicates, failed syntax attempts, or unusual access by application database users. After remediation, run regression tests for affected database access paths and confirm no JDBC connections are established in simple query mode.

Typical attack path

1. Find an application endpoint or API parameter that influences a Redshift query.
2. Confirm or infer that the application uses the Amazon Redshift JDBC Driver before version 2.1.0.28.
3. Confirm or infer that the JDBC connection string explicitly sets `preferQueryMode=simple`.
4. Target application functionality where user input is bound into SQL that negates a parameter value.
5. Submit crafted input designed to alter the SQL logic generated by the application and driver combination.
6. Use the manipulated query behavior to bypass filters, access unauthorized rows, modify data, or disrupt database-backed functionality.
7. Repeat against higher-value queries or accounts if the application database role has broad Redshift permissions.

How to detect it

To determine whether this was already exploited, correlate application request logs, API gateway or web server logs, application error logs, JDBC/database exception logs, and Amazon Redshift audit/query logs. Focus on applications that used an affected driver version and explicitly configured `preferQueryMode=simple`. In application logs, look for parameters containing SQL metacharacters, comment markers, tautologies, encoded quotes, or repeated probing that coincides with database syntax errors or unusual response sizes. In Redshift, review user activity logs, query logs, STL_QUERY, STL_ERROR, STL_UTILITYTEXT, SVL_STATEMENTTEXT, and related audit exports for unexpected predicates, comments, UNION-style probes, information schema reconnaissance, unauthorized SELECTs, DDL, COPY/UNLOAD activity, or queries issued by application users outside expected application behavior. Pay special attention to query text generated by application service accounts after suspicious HTTP requests. Absence of a generic IOC does not prove safety because payloads are application-specific and exploitation depends on the affected SQL pattern.

• preferQueryMode=simple
• preferQueryMode%3Dsimple
• com.amazon.redshift.jdbc.Driver
• redshift-jdbc42
• redshift-jdbc
• Amazon Redshift JDBC Driver
• SQLState
• syntax error at or near
• unterminated quoted string
• ERROR: syntax error
• ERROR: unterminated quoted string
• UNION SELECT
• union select
• information_schema.tables
• information_schema.columns
• pg_catalog
• --
• /*
• */
• ' OR '1'='1
• " OR "1"="1
• OR 1=1
• or 1=1
• ; DROP TABLE
• ;DROP TABLE
• UNLOAD (
• COPY
• STL_QUERY
• STL_ERROR
• SVL_STATEMENTTEXT

What your security team should do

• Inventory all applications and services that use the Amazon Redshift JDBC Driver, including packaged applications, data pipelines, ETL jobs, BI middleware, and container images.
• Prioritize internet-facing, partner-facing, and high-privilege applications that connect to Redshift and accept user-controlled input.
• Upgrade the driver to version 2.1.0.28 or later, or confirm inclusion of fix commit `51af003d4be170042faef20dadbcf4f992e10d8a`.
• Immediately remove `preferQueryMode=simple` from Redshift JDBC connection strings and configuration because the default query mode is not affected.
• Search code for vulnerable SQL construction involving negated parameter values and verify all user input remains safely parameterized.
• Review Redshift audit logs and application logs for suspicious SQL injection patterns, especially around endpoints that recently returned database errors or unusual result sets.
• Reduce Redshift permissions for application roles to the minimum required privileges, especially write, DDL, unload/export, and administrative capabilities.
• Because this is not currently in KEV and EPSS is low, track it as high severity for confirmed exposure rather than assuming broad exploitation across all Redshift JDBC users.