Security Advisories (2)
CVE-2026-108518 (2026-10-20)

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 (2026-10-20)

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.

NAME

dbilogstrip - filter to normalize DBI trace logs for diff'ing

SYNOPSIS

Read DBI trace file dbitrace.log and write out a stripped version to dbitrace_stripped.log

dbilogstrip dbitrace.log > dbitrace_stripped.log

Run yourscript.pl twice, each with different sets of arguments, with DBI_TRACE enabled. Filter the output and trace through dbilogstrip into a separate file for each run. Then compare using diff. (This example assumes you're using a standard shell.)

DBI_TRACE=2 perl yourscript.pl ...args1... 2>&1 | dbilogstrip > dbitrace1.log
DBI_TRACE=2 perl yourscript.pl ...args2... 2>&1 | dbilogstrip > dbitrace2.log
diff -u dbitrace1.log dbitrace2.log

DESCRIPTION

Replaces any hex addresses, e.g, 0x128f72ce with 0xN.

Replaces any references to process id or thread id, like pid#6254 with pidN.

So a DBI trace line like this:

-> STORE for DBD::DBM::st (DBI::st=HASH(0x19162a0)~0x191f9c8 'f_params' ARRAY(0x1922018)) thr#1800400

will look like this:

-> STORE for DBD::DBM::st (DBI::st=HASH(0xN)~0xN 'f_params' ARRAY(0xN)) thrN