CVE-2026-78183 in DBD::Pg
Summary
by MITRE • 08/23/2026
DBD::Pg version 3.21.0 for Perl has a heap out-of-bounds write in quote_float.
quote_float() allocates the length of the string + 1, which is the size of the bare numeric symbol plus NULL. But for special literals NaN, Inf, +Inf, -Inf, Infinity, +Infinity, -Infinity it emits the literal surrounded by quotes plus NULL, which is length + 3 bytes. Every recognised literal (case-insensitive) overflows by 2 bytes, a single quote and a NULL.
This can be reached by the $dbh->quote method, for example
$dbh->quote( "Infinity", DBI::SQL_NUMERIC ).
This regression was introduced in 3.21.0 by the quote.c rewrite.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in DBD::Pg version 3.21.0 represents a critical heap-based buffer overflow within the Perl database driver for PostgreSQL, specifically located in the quote_float function. This flaw stems from an incorrect calculation of memory allocation sizes when handling special floating-point literals such as NaN, Inf, +Inf, -Inf, Infinity, and their signed or unsigned variants. The root cause lies in a regression introduced during version 3.21.0 through a rewrite of the quote.c module, where the developers failed to account for the additional characters required when formatting these specific numeric symbols into SQL strings.
Technically, the function allocates memory based on the length of the input string plus one byte for the null terminator, assuming that the output will match or be smaller than the input size in most standard cases. However, special literals require enclosure within single quotes to be valid SQL syntax when passed as numeric data types. For instance, a literal like Infinity is three characters longer than its quoted representation would imply if not handled correctly, but more critically, the code allocates space for the bare symbol plus null while writing out the quoted version which includes two additional quote marks and potentially alters length expectations. Specifically, every recognized special literal overflows by exactly two bytes: one byte for an opening single quote and another implied miscalculation regarding the closing quote or null handling in the write operation context described. This results in a heap out-of-bounds write where data is written beyond the allocated buffer boundary.
The operational impact of this vulnerability allows for potential memory corruption, which can lead to application crashes, denial of service conditions, or more severely, arbitrary code execution if an attacker can control the contents adjacent to the affected heap chunk. Since DBD::Pg interacts directly with Perl's internal data structures and database connections, exploiting this flaw could compromise the integrity of the entire system running the vulnerable driver. An attacker might achieve remote code execution by crafting a malicious query that triggers the quote_float function with specific special literals, thereby overwriting adjacent memory regions such as heap metadata or other objects within the same allocation zone.
This vulnerability aligns with CWE-122, Heap-based Buffer Overflow, and falls under MITRE ATT&CK technique T1059, Command and Scripting Interpreter, specifically in contexts where Perl scripts are used for administrative tasks or web application backends that interface with PostgreSQL databases. The flaw is particularly dangerous because it occurs during a common database interaction method, $dbh->quote, which is frequently used to safely escape user input before embedding it into SQL statements. By passing values like Infinity via DBI::SQL_NUMERIC type hints, the vulnerability is triggered automatically by legitimate-looking code paths that rely on proper escaping mechanisms.
Mitigation strategies should prioritize immediate upgrading of the DBD::Pg module to a patched version where this regression has been corrected in subsequent releases. Until an official patch is available or deployed, administrators and developers can implement workarounds such as avoiding the use of special floating-point literals like Infinity or NaN when using the quote method with SQL_NUMERIC types. Alternatively, switching to alternative quoting mechanisms that do not rely on the vulnerable function path may reduce exposure. It is also recommended to review application code for any direct usage of $dbh->quote with numeric type hints containing these specific string values and refactor those calls to use parameterized queries or safe casting methods provided by modern database abstraction layers where possible.