There are 5 open security issues in trixie.
2 important issues:
- CVE-2026-108518:
DBI versions before 1.656 for Perl crash via type confusion in dbi_profile when a database handle is destroyed under a Profile Path with an {attr} element. An {attr} element names a database handle attribute, which dbi_profile reads from the handle's inner hash. It expects the inner handle as a reference and dereferences it, but a handle that is being destroyed hands back the inner hash itself, so the dereference yields the hash's bucket array. A type check on that pointer usually fails and the call goes unprofiled. When the memory it addresses passes the check, the attribute lookup dereferences a NULL or invalid pointer and the process dies on SIGSEGV. The Path is set by the application, by the Profile handle attribute, or by the DBI_PROFILE environment variable, so `DBI_PROFILE={ImplementorClass}` can crash an unmodified program.
- CVE-2026-111879:
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. open_data creates the table's lock file and takes an exclusive flock on it for a CREATE, before the checks that can croak: a dbm_mldbm value that is not a module name, a failing tie, or a missing data file. The croak unwinds before the table object is blessed, so nothing releases the lock, and the meta data holding the open descriptor stays cached on the database handle. The dbm_mldbm and dbm_type values come from the DSN or the connect attributes, so a caller that chooses the serializer or the storage backend can trigger the failure. The flock has no timeout, so a later open of that table (even through a separate database handle) blocks for as long as the handle holding the stale lock lives, in the same process or any other.
3 issues left for the package maintainer to handle:
- CVE-2026-78030:
(needs triaging)
DBI versions before 1.653 for Perl load arbitrary modules via unvalidated dbm_type and dbm_mldbm attributes in DBD::DBM. DBD::DBM passes the dbm_type and dbm_mldbm connect attributes to require without checking that the value names a module. require treats a path-shaped string as a literal filename and does not consult @INC, so the attribute chooses the file that Perl loads and runs. The MLDBM::Serializer:: prefix that DBD::DBM prepends to dbm_mldbm is not a boundary: only the :: separators are rewritten to /, so a value containing / traverses out of the serializer directory. The value is also assigned to $MLDBM::Serializer, which MLDBM requires the same way when it ties the table. A caller that lets an untrusted party influence either attribute, for example through a DSN fragment or a parameter that selects a storage backend, runs the file-scope code of whatever module the value names. For example, my $dsn = "dbi:DBM:f_dir=/var/db;dbm_type=../../Untrusted.pm" my $dbh = DBI->connect( $dsn ); Note that DBD::Gofer forwards connect attributes to the server side, and DBI::ProxyServer checks only that a DSN starts with a driver prefix.
- CVE-2026-88815:
(needs triaging)
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. This is reachable in Perl using the sql_type_cast function: my $num = 42; DBI::sql_type_cast( $num, DBI::SQL_NUMERIC, 0 );
- CVE-2026-88816:
(needs triaging)
DBI versions before 1.654 for Perl incorrectly treat numeric values as strings in FetchHashKeyName. fetchrow_hashref uses the string pointer of the FetchHashKeyName attribute as the key name without stringifying it first. When FetchHashKeyName has been set to an integer (IV) or floating-point (NV) value, that pointer is invalid, so reading the key name triggers a segmentation fault. This can be triggered with the following code: my $dbh = DBI->connect( "dbi:ExampleP:", "", "", { RaiseError => 0, PrintError => 0 } ); $dbh->{FetchHashKeyName} = 42; my $sth = $dbh->prepare("select mode, size, name from ."); $sth->execute; $sth->fetchrow_hashref;
You can find information about how to handle these issues in the security team's documentation.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/libd/libdbi-perl.png){kind=link}