CVE-2026-107349 in PgBouncer
Summary
by MITRE • 10/14/2026
An infinite loop in PgBouncer 1.20.0 through 1.26.0 allows an unauthenticated remote attacker to cause a denial of service. A StartupMessage whose options parameter contains an empty parameter name, such as "-c=", makes the ignore_startup_parameters list lookup loop forever. Because PgBouncer serves all clients from a single process, this saturates a CPU core and makes PgBouncer unresponsive to all clients until the process is restarted.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in PgBouncer versions 1.20.0 through 1.26.0 represents a critical denial of service risk stemming from improper input validation within the connection handling logic. Specifically, an infinite loop occurs when processing StartupMessage packets that contain malformed options parameters. The technical root cause lies in how the software handles parameter names during the initialization phase of a client connection. When a remote attacker sends a StartupMessage with an empty parameter name, such as "-c=", the internal lookup mechanism for the ignore_startup_parameters list fails to terminate correctly. Instead of recognizing the invalid format and rejecting it or skipping it, the logic enters an infinite loop while attempting to match the malformed entry against known configuration parameters. This behavior indicates a fundamental flaw in boundary condition handling and input sanitization during the parsing of client-supplied data structures.
From an operational perspective, this vulnerability has severe consequences for system availability because PgBouncer is designed as a connection pooler that typically operates using a single-process architecture to manage multiple concurrent database connections efficiently. The infinite loop consumes one hundred percent of a CPU core dedicated to processing that specific malicious request. Since the process handles all clients sequentially or within a limited thread context, this saturation effectively freezes the entire PgBouncer instance. Legitimate users attempting to connect to backend PostgreSQL databases are unable to establish sessions, resulting in a complete service outage for any application relying on this proxy layer. The impact is particularly acute because no authentication is required to exploit this flaw; an unauthenticated remote attacker can trigger the condition simply by sending a crafted network packet to the exposed PgBouncer port.
This incident aligns with CWE-835, which describes loops that do not terminate properly due to incorrect loop control logic or missing exit conditions based on input validation failures. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK frameworks, this vulnerability facilitates Denial of Service (T1499) by exhausting computational resources through resource exhaustion techniques. The attacker leverages the application's inability to gracefully handle malformed protocol messages to degrade service quality and availability without needing valid credentials or prior access privileges. This highlights a significant gap in robustness testing for network-facing services that parse complex binary or structured text protocols like PostgreSQL's startup message format.
Mitigation strategies must prioritize immediate patching of PgBouncer to version 1.26.1 or later, where the developers have addressed this specific parsing logic error. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict access to the PgBouncer port exclusively from trusted application servers using firewall rules or security groups. Additionally, deploying a Web Application Firewall or intrusion prevention system capable of inspecting and blocking malformed protocol packets can provide an interim layer of defense against exploitation attempts. Security teams should also monitor for unusual spikes in CPU usage on hosts running PgBouncer, as this may indicate active probing or successful exploitation of the infinite loop condition. Regular vulnerability assessments focusing on connection poolers and database proxies are essential to identify similar input validation weaknesses before they can be leveraged by adversaries.