CVE-2026-121265: SQL::Abstract versions before 2.000003 for Perl allow SQL injection via an arrayref column value in insert and update

Published Nov 7, 2026

Updated

SQL::Abstract versions before 2.000003 for Perl allow SQL injection via an arrayref column value in insert and update.

With the arraydatatypes option off, which is the default, insert(), update() and values() treat an arrayref column value as literal SQL. Its first element goes into the SQL text unescaped and the rest become bind values. A JSON array, or a repeated form field decoded as an arrayref, is such a value.

An application that passes request data as column values to insert or update with the default options allows SQL injection.

Releases before 2.000003 also treat an arrayref in generate() as literal SQL, including through AUTOLOAD when allowautoload is on, whatever arraydatatypes is set to.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade SQL::Abstract to a version that resolves this vulnerability.
Fixed in 2.000003

Event History

Nov 7, 2026

CVE Published

via MITRE·11:17 AM

Data Sourced

via MITRE·11:17 AM

RemedyDescriptionWeakness

Data Sourced

via NVD·12:17 PM

DescriptionWeakness

Frequently Asked Questions

Are applications using the default configuration affected?

Yes, if they pass request-derived values directly as column values to insert(), update(), or values(). The array_datatypes option is off by default, causing arrayrefs to be treated as literal SQL in those methods.

What attacker-controlled input can trigger the issue?

An attacker needs to cause a column value to be decoded or represented as an arrayref. Examples given include a JSON array and repeated form fields that are decoded as an arrayref.

Does enabling array_datatypes address every affected code path?

No. In releases before 2.000003, generate() treats an arrayref as literal SQL regardless of the array_datatypes setting. This also applies when generate() is reached through AUTOLOAD with allow_autoload enabled.

How can teams identify potentially exposed application code?

Check for SQL::Abstract versions before 2.000003 and calls to insert(), update(), values(), or generate() that receive request-derived column values. Pay particular attention to endpoints accepting JSON arrays or repeated form parameters.

What can be done while an upgrade is pending?

Avoid passing request-derived arrayrefs as column values, especially to insert(), update(), values(), and generate(). For insert(), update(), and values(), review whether array_datatypes is disabled, since that is the default affected configuration.

CVE-2026-121265: SQL::Abstract versions before 2.000003 for Perl allow SQL injection via an arrayref column value in insert and update

Remediation

Event History

Frequently Asked Questions

Are applications using the default configuration affected?

What attacker-controlled input can trigger the issue?

Does enabling array_datatypes address every affected code path?

How can teams identify potentially exposed application code?

What can be done while an upgrade is pending?

Company

Resources

Contact

Frequently Asked Questions

Are applications using the default configuration affected?

What attacker-controlled input can trigger the issue?

Does enabling array_datatypes address every affected code path?

How can teams identify potentially exposed application code?

What can be done while an upgrade is pending?