ALPINE-CVE-2026-121007: SQL Injection

Q: Which application patterns are exposed to exploitation?

An application is exposed only if it passes untrusted input as a where value inside a nested statement used in an identifier position. Affected identifier positions include the select list, ORDER BY, GROUP BY, RETURNING, and, with the ExtraClauses plugin, FROM (-as) and JOIN (to).

Q: Are nested subselects used in WHERE conditions affected?

No. Subselects in a WHERE condition are not affected by this issue.

Q: What happens to the attacker-controlled value in an affected query?

The nested statement's where, having, and set values, and rows of -values, are inserted into SQL text rather than the bind list. They are unescaped unless quote_char is set, enabling SQL injection when the value is untrusted.

Q: Is there a configuration that changes the immediate injection behavior?

Setting quote_char causes the affected values to be quoted rather than left unescaped. The data does not state that this fully remediates the issue, so applications should also avoid passing untrusted input in the affected nested-statement where values.

Published Nov 4, 2026

Updated

SQL::Abstract versions from 1.9001 before 2.00000104 for Perl allow SQL injection via the where values of a nested statement in an identifier position.

A nested statement such as { -select => ... } in a position where plain scalars are identifiers treats its own plain scalars as identifiers too. These positions are the select list, ORDER BY, GROUP BY, RETURNING, and with the ExtraClauses plugin FROM (-as) and JOIN (to). The values of the statement's where, having and set clauses, and the rows of a -values, go into the SQL text instead of the bind list, unescaped unless quotechar is set. Subselects in a WHERE condition are not affected.

An application that passes untrusted input as a where value of such a nested statement, expecting it to be bound, allows SQL injection.

Affected Software

1 affected componentFixes available

alpine/perl-sql-abstract<2.000003-r0

2.000003-r0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade alpine/perl-sql-abstract to a version that resolves this vulnerability.
Fixed in 2.000003-r0
Upgrade
Upgrade SQL::Abstract to a version that resolves this vulnerability.
Fixed in 2.000001_04

Event History

Nov 4, 2026

CVE Published

via OSV·03:17 PM

Data Sourced

via OSV·03:17 PM

DescriptionAffected Software

Frequently Asked Questions

Which application patterns are exposed to exploitation?

An application is exposed only if it passes untrusted input as a where value inside a nested statement used in an identifier position. Affected identifier positions include the select list, ORDER BY, GROUP BY, RETURNING, and, with the ExtraClauses plugin, FROM (-as) and JOIN (to).

Are nested subselects used in WHERE conditions affected?

No. Subselects in a WHERE condition are not affected by this issue.

What happens to the attacker-controlled value in an affected query?

The nested statement's where, having, and set values, and rows of -values, are inserted into SQL text rather than the bind list. They are unescaped unless quote_char is set, enabling SQL injection when the value is untrusted.

Is there a configuration that changes the immediate injection behavior?

Setting quote_char causes the affected values to be quoted rather than left unescaped. The data does not state that this fully remediates the issue, so applications should also avoid passing untrusted input in the affected nested-statement where values.

ALPINE-CVE-2026-121007: SQL Injection

Affected Software

Remediation

Event History

Frequently Asked Questions

Which application patterns are exposed to exploitation?

Are nested subselects used in WHERE conditions affected?

What happens to the attacker-controlled value in an affected query?

Is there a configuration that changes the immediate injection behavior?

Company

Resources

Contact

Frequently Asked Questions

Which application patterns are exposed to exploitation?

Are nested subselects used in WHERE conditions affected?

What happens to the attacker-controlled value in an affected query?

Is there a configuration that changes the immediate injection behavior?