CVE-2026-108518

DBI versions before 1.653 for Perl load arbitrary modules via unvalidated dbm_type and dbm_mldbm attributes in DBD::DBM. These attributes are passed to require without checking that the value names a module, allowing loading and executing code from any file.

In DBI for Perl before version 1.652, a heap out-of-bounds write occurs via an unvalidated numeric placeholder that sets the binder counter in preparse. A crafted statement can cause a write beyond the allocated buffer.

In DBI for Perl before version 1.652, a heap out-of-bounds write occurs on 32-bit Perl due to integer wraparound in the output buffer size computed by preparse. A very long statement can cause a write beyond the allocated buffer.

A vulnerability in the DBI library for Perl before version 1.651 does not enforce statement handle consistency with the row. When the statement handle had no fields but the source row was non-empty, the internal row-buffer helper would read from a negative array index.

A vulnerability in the DBI library for Perl before version 1.650 causes an out-of-bounds read by one byte during processing of an initial SQL comment in the preparse method. The issue occurs when deleting a comment at the beginning of an SQL query.

A heap overflow vulnerability in DBI versions before 1.650 for Perl occurs when preparsing SQL statements with an extreme number of placeholders. The fix for CVE-2026-10879 did not allocate enough memory to handle approximately 1.2 million placeholders. Version 1.650 sets a hard limit of 99,999 placeholders.

DBI for Perl before version 1.648 saves error messages in a limited-size buffer (200 bytes) without length control. Attackers who can influence error text may cause a buffer overflow.

DBI versions before 1.656 for Perl hang on a later open of a DBD::DBM table because a failed open_data does not release the table's lock. The flock has no timeout, so a later open of that table blocks for as long as the handle holding the stale lock lives.

DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in FetchHashKeyName. When FetchHashKeyName is set to an integer (IV) or floating-point (NV) value, the string pointer is invalid, so reading the key name triggers a segmentation fault.

DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in sql_type_cast_svpv. When casting to SQL_NUMERIC, sql_type_cast_svpv passes the string pointer and length of the SV to grok_number without stringifying it first; an integer (IV) or floating-point (NV) value has no valid string pointer, so grok_number reads from an invalid address, triggering a segmentation fault.