CVE-2026-78030 in DBI
Summary
by MITRE • 09/19/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/19/2026
The vulnerability identified in Perl Database Interface (DBI) versions prior to 1.653 represents a critical insecure module loading flaw within the DBD::DBM database driver. This issue stems from insufficient validation of user-supplied input passed through specific connect attributes, namely dbm_type and dbm_mldbm. When establishing a connection via these attributes, the underlying code invokes Perl's require function to load modules without verifying that the provided values correspond exclusively to valid module names. In standard Perl execution contexts, requiring an arbitrary file path can lead to the execution of untrusted code if the input is not strictly controlled. This behavior violates fundamental security principles regarding the safe handling of dynamic library loading and constitutes a significant risk for applications relying on DBI for database interactions where user input influences connection parameters.
The technical mechanism of this exploitation relies on how Perl's require function interprets its arguments when presented with path-shaped strings. Unlike module names that are resolved against the @INC directory list, paths containing slashes or other separators are treated as literal file system locations. Consequently, an attacker who can influence the dbm_type attribute can specify a relative or absolute path to any executable script on the server's file system. The DBD::DBM driver passes this unvalidated string directly into require, effectively allowing the execution of arbitrary Perl code with the privileges of the process running the database connection logic. This bypasses standard module namespace protections and grants an attacker direct control over the application's runtime environment through a seemingly innocuous configuration parameter.
A secondary vector for exploitation involves the dbm_mldbm attribute, which is designed to specify MLDBM serializer modules. DBD::DBM attempts to mitigate risks by prepending the MLDBM::Serializer:: prefix to this value and converting double colon separators into forward slashes to form a file path. However, this sanitization logic is flawed because it only replaces :: with / without validating that the resulting string remains within the intended serializer directory structure. If an attacker includes forward slash characters in their input, they can perform directory traversal attacks by using sequences such as ../../ to escape the MLDBM::Serializer namespace and access arbitrary files elsewhere on the file system. Furthermore, this value is also assigned to the $MLDBM::Serializer variable, which MLDBM uses when tying tables, providing an alternative code execution path even if the initial require call were somehow restricted.
The operational impact of this vulnerability is severe, particularly in environments where database connection strings are constructed from user-controlled data or configuration files that can be manipulated by external actors. For instance, a web application allowing users to select their preferred storage backend via a URL parameter could inadvertently pass malicious values for dbm_type or dbm_mldbm directly into the DBI connect call. Successful exploitation allows an attacker to execute arbitrary code on the server, potentially leading to full system compromise, data exfiltration, or lateral movement within the network infrastructure. The risk is further amplified in distributed architectures using DBD::Gofer, which forwards connect attributes to a remote database server side, and by DBI::ProxyServer, which currently only validates that a Data Source Name starts with a driver prefix without inspecting the internal parameters for malicious payloads.
To mitigate this vulnerability, it is imperative to upgrade DBI to version 1.653 or later, where these input validation flaws have been addressed. For systems unable to immediately patch, developers must implement strict allow-lists for any database connection attributes that are derived from user input. Specifically, the dbm_type and dbm_mldbm values should be validated against a predefined list of known safe modules before being passed to DBI::connect. Additionally, application logic should avoid constructing DSN fragments directly from untrusted sources such as HTTP parameters or configuration files without rigorous sanitization. Security teams should also review any use of DBD::Gofer and DBI::ProxyServer configurations to ensure that forwarded attributes are subject to the same validation standards as local connections.
From a classification perspective, this vulnerability aligns with CWE-94, which describes Improper Control of Generation of Code or Command, specifically in contexts where user input influences code generation without proper validation. It also relates closely to CWE-20, indicating improper input validation that allows an attacker to bypass intended security controls by injecting malicious paths into module loading routines. In terms of the MITRE ATT&CK framework, this flaw facilitates Initial Access and Execution techniques, as it enables attackers to leverage trusted system components like database drivers to execute arbitrary code on compromised hosts. Understanding these mappings helps in prioritizing remediation efforts and aligning patch management with broader security operations frameworks focused on preventing remote code execution through input validation failures.