Revision history for SQL::Abstract 2.000003 - 2026-11-06 - SECURITY, CVE-2026-121265: generate() (and so AUTOLOAD with allow_autoload) also treats an arrayref in its hashref or arrayref as one bind value. 2.000002 fixed only insert(), update() and values(): generate('update t', { name => [ "(SELECT ...)" ] }) still gave UPDATE T SET name = (SELECT ...). \[ $sql, @bind ] is literal SQL in generate() too; array_datatypes => 0 restores the old behaviour. - every module has a $VERSION, the same as SQL::Abstract 2.000002 - 2026-11-05 - SECURITY, CVE-2026-121265: array_datatypes is on by default, so an arrayref as a column value in insert() or update() (and values()) is one bind value. Before, it was literal SQL and its first element went into the SQL text: a JSON array or a repeated form field like { name => [ "x, is_admin = 1" ] } gave UPDATE t SET name = x, is_admin = 1. Literal SQL is \[ $sql, @bind ]; array_datatypes => 0 restores the old behaviour. Incompatible for code that used a plain arrayref as literal SQL. - SECURITY, CVE-2026-121007: the where / having / set values of a nested statement ({ -select => ... }, { -update => ... } ...) in a select list, ORDER BY, GROUP BY, RETURNING, FROM (-as) or JOIN (to) became identifiers and went into the SQL text instead of @bind - without quote_char unescaped, so { id => "1 OR 1=1" } ended up as WHERE id = 1 OR 1=1. They are bind values again. The same goes for the rows of a { -values => ... } in FROM. - SECURITY, CVE-2026-121008: the html profile of SQL::Abstract::Tree HTML-escapes the SQL text and the filled in bind values (new html_escape option); before, a bind value like