PgBouncer CVE-2025-12819: Upgrade to 1.25.1 to Stop Auth Time SQL Execution

PgBouncer has a serious authentication-path vulnerability—CVE-2025-12819—that can let an unauthenticated client execute arbitrary SQL during the authentication process by supplying a crafted search_path parameter in the StartupMessage; the bug affects PgBouncer releases prior to 1.25.1 and was fixed in the 1.25.1 release published December 3, 2025.

Background / Overview​

PgBouncer is the widely used lightweight connection pooler for PostgreSQL. Its role as a proxy between clients and databases makes it an attractive target: a flaw in its authentication or query handling can be leveraged to gain access to the database before a backend ever sees a client’s credentials.
On December 3, 2025, the PgBouncer project released version 1.25.1 addressing CVE-2025-12819. The advisory and changelog describe the bug as an untrusted search path condition in the auth_query connection handler whereby a malicious StartupMessage containing a specially crafted search_path parameter can cause PgBouncer to run attacker-supplied SQL during the authentication phase. The release notes also enumerate the exact configuration preconditions that must be present for the issue to be exploitable. Independent vulnerability trackers and distribution security pages list the issue under CVE-2025-12819 and assign a CVSS 3.1 base score of 7.5 (High), reflecting its potential for confidentiality, integrity, and availability impact when the preconditions are met.

---

What went wrong — technical summary​

The vulnerability class: Untrusted search path (CWE-426)​

At a high level, CVE-2025-12819 is a classic untrusted search path weakness. PgBouncer accepted or used a client-supplied search_path in a context where it later executed or constructed SQL tied to authentication, and the search path could influence which schema-qualified objects were resolved. That allowed attackers to steer the resolver toward attacker-controlled objects or otherwise change SQL semantics during the critical auth phase. This is the same underlying class of risk that has produced other local privilege and elevation flaws in different products: if a component uses a search path provided by an untrusted actor to resolve critical symbols or objects, it can be tricked into running the wrong code or SQL.

Precise trigger conditions​

PgBouncer’s changelog makes clear this is not a pure one-click remote exploitation for default installs. Exploitation requires that all the following conditions are present:

• The server’s configuration uses track_extra_parameters and it includes search_path (this is not the default and is typically used in advanced/edge setups such as Citus or PostgreSQL 18 integrations).
• auth_user is set to a non-empty string (again, non-default; operators configure this when delegating auth to a single user account).
• The auth_query used by PgBouncer is configured without fully-qualified object names (many default or example auth_query settings use unqualified object references and thus are susceptible to search_path influence).

If all three are true, a malicious StartupMessage that injects a crafted search_path can cause PgBouncer to evaluate/authenticate using an attacker-controlled schema resolution, enabling arbitrary SQL execution during authentication.

---

Scope and affected versions​

• Affected releases: PgBouncer prior to 1.25.1. The project released 1.25.1 on December 3, 2025 to fix the issue.
• Distribution packaging: Debian and other distributions reflected the CVE in their trackers; Debian’s tracker shows package versions and the fixed version 1.25.1-1 appearing in unstable/sid, with earlier packages remaining vulnerable in older releases until they incorporate the update. Operators should inspect distribution package numbers rather than relying solely on CVE strings.
• Attack vector: Network (a client connects and sends a crafted StartupMessage). The CVSS vector used by public trackers places the attack as remotely reachable but with high complexity and low required privileges.

---

Impact analysis — what an attacker can do​

This vulnerability is high-impact in the right environment because it occurs at the authentication phase, where logic is expected to validate credentials and decide whether a client is permitted to connect. The consequences include:

• Arbitrary SQL execution during authentication — attacker-supplied SQL can run in the auth context and perform reads, writes, or metadata queries depending on the effective privilege of the auth user.
• Confidentiality breach — attackers could query sensitive tables, system catalogs, or leak data through auth-time responses.
• Integrity compromise — ability to modify schema, user roles, or configuration objects if the auth user has sufficient privileges.
• Availability damage — attacker SQL could cause resource exhaustion, long-running transactions, or deliberately crash the pooler or backend by triggering errors, thereby denying service to legitimate clients.

Public scoring (CVSS 7.5) accounts for the high-impact nature, but it also reflects that exploitation complexity is non-trivial because of the cascading configuration preconditions. In other words, when the required configuration is present, the impact is severe; where those settings are default, the practical exposure is much lower.

---

Exploitability: realistic attacker model and likelihood​

• Required access model
• The attacker needs only network connectivity to the PgBouncer listener; no prior authentication is required. That said, the attacker must craft a StartupMessage with a malicious search_path payload—something only possible during initial protocol negotiation.
• Preconditions make the attack selective
• Because the bug requires specific (non-default) configuration (see earlier), the average simple PgBouncer deployment is not automatically exploitable.
• Complexity and realism
• The exploit complexity is rated high by CVSS calculators—this reflects that an attacker must understand how the hosting environment uses auth_user, auth_query, and search_path to achieve a reliable arbitrary-SQL primitive. However, for operators who do run the exact configuration (for example multi-tenant Citus front-ends or specific PostgreSQL 18 integrations), the path can be straightforward and highly attractive to attackers.
• Public evidence
• At the time of disclosure there are no widely publicized proof-of-concept exploits in major code repositories; distribution scanners and vulnerability feeds reflect publication and the available fix but do not yet show active widespread exploitation. That said, untrusted search path vulnerabilities historically attract quick PoC development when the conditions are simple, so defenders should assume weaponization is likely to appear fast in the public domain.

---

Remediation — definitive fix and immediate mitigations​

Definitive remediation (recommended)​

• Upgrade to PgBouncer 1.25.1 or later as soon as practicable. The PgBouncer project fixed CVE-2025-12819 in the 1.25.1 release published December 3, 2025. This is the only guaranteed, protocol-correct fix.

Configuration mitigations (temporary controls if immediate patching is impossible)​

If you cannot upgrade immediately, reduce exposure by ensuring the attack preconditions cannot all hold simultaneously:

• Remove search_path from track_extra_parameters. If PgBouncer does not carry search_path across the auth handshake, the attacker gains no channel to inject the malicious path. (Beware operational impacts: some advanced setups rely on passing search_path to backend sessions.
• Unset auth_user or set it to an empty string if your deployment does not require it. If auth_user is not set to a non-empty string, the specific auth-time code path documented as vulnerable will not be exercised.
• Use fully-qualified object names in auth_query, especially schema-qualified names for tables and functions referenced by auth queries. If auth_query references objects with fully-qualified names, a manipulated search_path cannot redirect those names to attacker-controlled objects.
• Harden network access to PgBouncer: restrict connections to trusted IPs, use firewall rules to block untrusted networks, and place PgBouncer behind VPNs or private networks where possible.

These mitigations are configuration-level workarounds that reduce the practical attack surface until you can apply the upstream patch. The project changelog explicitly calls out these configuration nuances in its advisory text.

Operational checklist for urgent patching​

• Inventory all PgBouncer instances (on-prem, VMs, containers, cloud images).
• Identify versions and package builds (distribution packages may lag; check package metadata).
• Test PgBouncer 1.25.1 in a staging environment with your exact auth and connection workload.
• Deploy 1.25.1 to production in controlled waves; monitor connections and authentication paths after rollover.
• If patching is delayed, apply the configuration mitigations above and rotate any sensitive credentials that were accessible to older auth_user accounts.

---

Detection and monitoring — what to look for​

• Authentication anomalies: spikes in auth failures or unexpected auth-time messages during the startup exchange.
• Unexpected queries logged during authentication: if PgBouncer’s logging or backend logs record SQL executed during authentication, look for unusual or nonstandard queries tied to new client connections.
• Access patterns from unrecognized IPs: repeated StartupMessage attempts from attackers scanning for vulnerable endpoints.
• Audit for track_extra_parameters configuration: telemetry that reports effective PgBouncer configuration across fleet helps identify at-risk instances quickly.
• Centralized logging for PgBouncer: ensure startup parameters and connection negotiation are logged at sufficient granularity for forensic review.
• Alert on changes to auth_query: any recent modification to custom auth_query definitions that removed schema qualifiers should trigger a high-priority review.

Tenable / Nessus plugin and distro trackers are already flagging unpatched packages; run vulnerability scans and cross-check scanner findings against your asset inventory. Distribution trackers (Debian, etc. list the fixed package releases and can help prioritize which hosts need package upgrades.

---

Why this matters to production operators — practical scenarios​

• Multi-tenant front-ends and Citus setups often pass search_path as part of client session parameters for tenant isolation; such setups are particularly exposed if they also use auth_user for centralized authentication.
• Automated deployment pipelines or configuration-as-code that introduced a non-default track_extra_parameters across many instances can inadvertently expand exposure. A single missed configuration change can convert hundreds of proxies into remotely reachable attack surfaces.
• Managed hosting providers who offer PgBouncer as a service may need to patch customers’ tenants or force configuration changes, complicating remediation windows and rollback plans.

The combination of high-impact capability (SQL execution during auth) and the fact that PgBouncer sits in the critical path for client connections makes this a high-priority item wherever the vulnerable configuration exists.

---

Operational recommendations — prioritized​

• Patch: upgrade to PgBouncer 1.25.1 across all affected environments after successful staging validation. Schedule reboots/restarts with appropriate maintenance windows.
• Inventory & harden: identify instances with track_extra_parameters including search_path and auth_user set; remediate or isolate those first.
• Apply temporary configuration mitigations if you cannot patch immediately: remove search_path from tracked params, set auth_user to empty if feasible, and convert auth_query to use fully-qualified names.
• Network controls: block PgBouncer listener access from untrusted IP ranges; require VPN or bastion access for administrative endpoints.
• Logging and detection: increase logging detail at auth time, alert on unexpected auth-time SQL, and run fleet-wide vulnerability scans for package versions flagged by distribution feeds or Nessus/Tenable.
• Post-patch verification: after upgrading, validate that auth flows operate normally, and confirm that previously exploitable config states no longer produce unauthorized SQL execution.

---

Risk trade-offs and caveats​

• Not every PgBouncer instance is exposed. The project’s changelog is explicit that all documented preconditions must be true for remote arbitrary-SQL execution to be feasible. That reduces mass-exploit risk for default deployments but elevates the priority for complex or non-default setups.
• Distribution lag: packaged versions in stable distributions can remain vulnerable until maintainers backport the fix. Debian’s tracker shows older distro packages still marked vulnerable until they incorporate 1.25.1. Operators relying on vendor packages must verify the package’s changelog or update to a patched release.
• No authoritative public PoC at disclosure time: while public exploit code can appear rapidly for this class of flaw, as of disclosure scanners and trackers show the CVE but do not indicate an immediate epidemic of exploitation. That does not reduce the need for remediation—rather it is a small window to act before weaponization occurs.

---

Broader lessons — why untrusted search paths keep recurring​

Untrusted search path issues are a recurring architectural hazard: when a service resolves names, objects, or modules based on input it does not fully control, attackers can influence resolution and redirect execution or references to malicious artifacts. Fixes typically require:

• Enforcing canonical, fully-qualified references for security-sensitive operations.
• Avoiding reliance on client-supplied resolution contexts for actions performed before authorization is confirmed.
• Minimizing the amount of client-controlled metadata that an authentication or authorization component will accept and act on.

These principles apply across software ecosystems — from OS DLL load orders to SQL schema search_path handling — and are why central hardening (explicit qualification and least-privilege defaults) is a recurring recommended defense. The PgBouncer fix and the accompanying documentation updates (including examples switching to safe, schema-qualified auth_query examples) reflect that remediation pattern.

---

Conclusion​

CVE-2025-12819 is a high-impact vulnerability when it applies: an unauthenticated client can cause arbitrary SQL execution during PgBouncer’s authentication phase if several non-default configuration items are present. The PgBouncer team released 1.25.1 on December 3, 2025 to address the flaw, and distribution trackers and scanning engines have already cataloged the CVE and begun flagging vulnerable packages. Operators running PgBouncer should treat this as a high-priority remediation item for any instance that (a) tracks search_path, (b) uses auth_user, and (c) relies on unqualified auth_query objects. Immediate actions are simple: inventory, patch to 1.25.1, or apply the recommended configuration mitigations while scheduling an upgrade. For security teams, the pragmatic path is clear: verify which PgBouncer instances match the documented vulnerable configuration, apply 1.25.1 after testing, and in the interim remove search_path from tracked parameters or ensure schemas and auth_query entries are fully qualified—then monitor auth-time logs for anomalous SQL activity. The narrow technical preconditions mean an organization can rapidly triage risk and prioritize remediation where it matters most.

---

---

Source: MSRC Security Update Guide - Microsoft Security Response Center