CVE-2026-121007
Description
A flaw was found in SQL::Abstract. When processing nested statements placed in identifier positions, the library inserts clause values directly into raw database queries rather than parameterizing them as bound values. If an application incorporates untrusted input into these nested queries, an attacker can perform SQL injection, potentially allowing unauthorized access to, alteration of, or deletion of database contents.
Statement
Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.
Mitigation
--- CME Mitigation Guidance (2026-11-04) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to ensure nested statements in identifier positions do not interpolate raw user input and enforce parameter binding across all nested SQL::Abstract query clauses: upgrade to SQL::Abstract 2.000001_04+ (or the fixed Perl Sql Abstract builds), which localize $Default_Scalar_To to -value in _expand_statement and _expand_values so nested scalar inputs are bound as parameters, closing all 4 injection vectors (crafted input in nested where clauses, crafted input in nested having clauses, crafted input in nested set clauses, crafted input in nested values rows). Until patched, this is a concern on Applications using SQL::Abstract embedding untrusted input into nested statements within identifier positions without quote_char configured, so Avoid passing untrusted input into nested statements in identifier contexts like select lists, ORDER BY, GROUP BY, RETURNING, FROM, or JOIN clauses, or configure quote_char in SQL::Abstract. As a compensating measure, Deploy web application firewall inspection to detect and block HTTP requests containing SQL injection syntax before parameters reach the query builder and Enforce database least-privilege access control to restrict database user permissions and limit potential data alteration or deletion. These controls limit blast radius and contain exploitation, but they do not fix the underlying SQL injection defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-1305 SQL Injection Prevention (Parameterized Queries) (high)
Understanding the Weakness (CWE)
Confidentiality,Integrity,Availability
Technical Impact: Execute Unauthorized Code or Commands
Adversaries could execute system commands, typically by changing the SQL statement to redirect output to a file that can then be executed.
Confidentiality
Technical Impact: Read Application Data
Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities.
Authentication
Technical Impact: Gain Privileges or Assume Identity; Bypass Protection Mechanism
If poor SQL commands are used to check user names and passwords or perform other kinds of authentication, it may be possible to connect to the product as another user with no previous knowledge of the password.
Access Control
Technical Impact: Bypass Protection Mechanism
If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL injection vulnerability.
Integrity
Technical Impact: Modify Application Data
Just as it may be possible to read sensitive information, it is also possible to modify or even delete this information with a SQL injection attack.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
