SECURITYCRITICALCVE-2026-78030

CVE-2026-78030: Perl DBI Loads Arbitrary Modules via DBD::DBM

DBI before 1.653 lets attacker-influenced dbm_type/dbm_mldbm connect attributes make Perl require() and execute an arbitrary file.

Dylan H.

Security Team

September 20, 2026
3 min read
CVE-2026-78030: Perl DBI Loads Arbitrary Modules via DBD::DBM

Critical severity

Rated critical. Prioritise patching — see the remediation guidance below.

Affected Products

  • Perl DBI — versions before 1.653

Overview

A critical vulnerability in Perl's DBI module — the near-universal database interface layer for Perl applications — allows an attacker who can influence a database connection string to force Perl to load and execute an arbitrary file as code. Tracked as CVE-2026-78030 and rated 9.8 (Critical) on CVSS 3.1, it affects all DBI versions before 1.653.

The flaw lives in DBD::DBM, DBI's driver for simple DBM-style key-value databases, and is classified as CWE-470 (Unsafe Reflection) — untrusted input is used to select which code Perl loads and runs.


Technical Details

FieldValue
CVE IDCVE-2026-78030
SeverityCritical (CVSS 3.1: 9.8)
CWECWE-470 — Use of Externally-Controlled Input to Select Classes or Code
AffectedDBI (Perl) before 1.653
Fixed InDBI 1.653 (released 2026-09-09)
Related CVECVE-2026-15392 (symlink check hardening, fixed in the same release)

How It Works

DBD::DBM passes its dbm_type and dbm_mldbm connect attributes straight to Perl's require without verifying that the value actually names a legitimate module. require treats a path-shaped string as a literal filename rather than a module name — it never consults @INC — so whatever string is supplied in dbm_type or dbm_mldbm becomes the file Perl loads and executes at connect time.

DBD::DBM also prepends an MLDBM::Serializer:: prefix to dbm_mldbm values, intending to constrain the load to the serializer directory. That prefix is not an effective boundary: only the :: separators are rewritten to /, so a value containing / traverses out of the serializer directory entirely. The value is then also assigned to $MLDBM::Serializer, which MLDBM requires the same way once it ties the table — giving two separate unsafe load points from one attribute.

A minimal proof-of-concept connection string illustrates the issue:

dbi:DBM:f_dir=/var/db;dbm_type=../../Untrusted.pm

Any application that lets an untrusted party influence either attribute — for example through a DSN fragment, a query parameter that selects a storage backend, or a multi-tenant configuration value — will execute the file-scope code of whatever module name the attacker supplies. DBD::Gofer forwards connect attributes to its server side, and DBI::ProxyServer only validates that a DSN begins with a driver prefix, so both extend the exposure beyond directly embedded connection strings.


Impact Assessment

Any Perl application that:

  • Builds DBD::DBM connection strings from user-influenced input (tenant IDs, config selectors, API parameters), or
  • Runs behind DBD::Gofer or DBI::ProxyServer with attacker-reachable connect attributes

is at risk of arbitrary code execution in the context of the Perl process — which in many deployments runs with elevated filesystem or network privileges.


Mitigation

  • Upgrade to DBI 1.653 or later immediately
  • Never construct dbm_type or dbm_mldbm from untrusted input — treat them as trusted configuration, not request data
  • Audit DSN construction anywhere DBD::DBM is used with dynamic or tenant-supplied values
  • If running DBD::Gofer or DBI::ProxyServer, confirm connect attributes reaching those services are not attacker-controlled

References