CVE-2026-78030
DBI versions before 1.653 for Perl load arbitrary modules via unvalidated dbm_type and dbm_mldbm attributes in DBD::DBM
- State
- Published
- Severity
- 9.8 Critical
- Published
- Sep 19, 2026
- Updated
- Sep 20, 2026
- Reserved
- Aug 22, 2026
Description
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.
Scores
| CVSS | Score | Vector | Source |
|---|---|---|---|
| 3.1 | 9.8 Critical | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | CISA-ADP |
Weaknesses
- CWE-470 Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')
Affected Products
| Product | Versions |
|---|---|
DBI |
|
References
- https://metacpan.org/release/HMBRAND/DBI-1.653/changesrelease-notes
- https://github.com/perl5-dbi/dbi/commit/315c6ce703b8b3cbe9188062d9ec80730293554a.patchpatch
- https://github.com/perl5-dbi/dbi/security/advisories/GHSA-wqmw-wqwx-3fr7vendor-advisory
- http://www.openwall.com/lists/oss-security/2026/09/19/4
Every record here comes from the CVE Program’s CVE List. © 1999–2026 The MITRE Corporation. CVE is a registered trademark of The MITRE Corporation. The records are reproduced under the CVE Program terms of use.