Pgpool-II, the connection pooler and automatic failover layer that sits in front of PostgreSQL, shipped five releases on October 1, 2026(versions 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21) patching seven CVEs that all live in the same place: the watchdog and failover message-processing path. Two of them are authentication bypasses, and one of those lets an attacker choose which node becomes watchdog leader.

CVE-2026-92873 is the one that matters most in a multi-node deployment. An attacker who can reach the watchdog port can bypass the inter-node authentication key and promote a node of their choosing to leader. Since leader election governs failover, that is control of the availability plane for the whole pool, not one process. Separately, CVE-2026-92868 lets a client authenticate as a different user with no password, because a NUL byte in the common name of a client X.509 certificate is not handled correctly.

Key takeaways:

  • CVE-2026-92873 is a watchdog leader-election bypass. In a cluster, treat it as full compromise of the failover control plane.
  • CVE-2026-92868 is a client-certificate authentication bypass via a NUL byte in the CN. Anyone relying on certificate auth for Pgpool-II should treat it as urgent.
  • Four of the seven are memory-safety bugs in malformed-watchdog-message parsing: arbitrary writes, out-of-bounds writes, stack corruption and a NULL dereference.
  • All five releases cover all seven CVEs. The announcement does not map individual CVEs to individual branches, so do not assume your branch needs only some of them.
  • Risk scales with topology. A single-node pool is far less exposed than a multi-node one with a configured auth key.

The seven CVEs

CVEClassWhat it allows
CVE-2026-92873Authentication bypassBypass auth-key checks and promote a watchdog node of the attacker’s choice to leader
CVE-2026-92868Authentication bypassNUL bytes in the CN of a client X.509 certificate are not handled; a malicious client can connect as another user without a password
CVE-2026-92867Memory safetyArbitrary 32-bit write to an arbitrary memory address via a malformed watchdog message during failover
CVE-2026-92869Memory safetyWrite beyond the bounds of a fixed-size array via a malformed watchdog message
CVE-2026-92870Memory safetyArbitrary-length write corrupting the stack, crashing the Pgpool-II process
CVE-2026-92871Denial of serviceNULL pointer dereference in inter-node authentication when an auth key is configured and crafted messages omit authentication information
CVE-2026-92872Information disclosureInformation disclosure in the heartbeat receiver process
Pgpool Global Development Group announcement, hosted on postgresql.org, 1 October 2026.

Why leader-election bypass is the serious one

Pgpool-II’s watchdog exists to stop split-brain. Nodes hold a shared lock, and the watchdog leader is the node that decides when the primary has failed and failover should occur. Nodes authenticate their messages to each other with a configured auth key, and that key is the trust boundary.

CVE-2026-92873 removes that boundary: an attacker who can send watchdog messages can promote a node of their choice to leader without the key. In a multi-node pool that means controlling which backend is considered live, and by extension controlling when failover happens.

Compare that to the impact of a crash. A process that dies is visible, and the pool recovers. A process that does not die but is running on an attacker’s terms is not visible, and failover is precisely the mechanism that would normally stop you noticing. That asymmetry is why an authentication bypass ranks above the memory-safety issues in this set even though the memory-safety issues sound more dramatic.

If you cannot patch immediately, the mitigation is network reachability: the watchdog port must not be reachable by anything except the other pool nodes. Watchdog traffic crossing a network boundary is the condition that turns this from a theoretical issue into a real one.

A NUL byte in a certificate common name

CVE-2026-92868 is a different failure with an equally clean explanation. A client certificate’s common name identifies the user. If a malicious client can get a NUL byte into that common name and Pgpool-II does not handle it correctly, the string that is compared is not the string that was validated. The name truncates, and the client authenticates as whoever owns the prefix.

This is why NUL handling is a recurring theme in authentication bugs. C treats strings as NUL-terminated. Anything that crosses that boundary, into a language with counted strings, into a database column, into a log line, into a comparison function — can disagree about what the value is. Certificate parsing is one of the more dangerous places for that disagreement, because the value decides who you are.

If you use Pgpool-II client certificate authentication, do not wait for the patch to audit how those CNs were issued. Any certificate whose subject contains an embedded NUL is a credential worth reviewing on its own.

Why the same bug shipped in five releases

Five releases from one announcement is standard practice for a project that maintains long-lived branches, and it is a good discipline: it means a deployment pinned to 4.3 is not left unpatched because it is old. It also means you cannot reason about which bugs affect you from your version number.

The announcement states that the seven CVEs are covered across all five releases. It does not publish a per-branch CVE mapping. So the correct reading is not “I am on 4.5 so three of these do not apply to me”, it is “every supported branch needs the patch, and my branch needs whichever is the latest of the five for that line.”

Your branchUpgrade to
4.7.x4.7.3
4.6.x4.6.8
4.5.x4.5.13
4.4.x4.4.18
4.3.x4.3.21
All five releases are dated 1 October 2026 and cover all seven CVEs.

Assessing your own exposure

  • Are you multi-node? Single-node deployments have no watchdog leader to promote and no inter-node auth to bypass, so CVE-2026-92873 and CVE-2026-92871 do not apply in the same way.
  • Is the watchdog port reachable beyond the pool? That is the single most important question. It should not be.
  • Do you use client certificate authentication? If yes, CVE-2026-92868 is your most urgent item regardless of topology.
  • Is your Pgpool-II version supported? Branches below 4.3 are not in this announcement.

None of these seven CVEs are described as actively exploited in the announcement, so this is not an incident-response item for most operators. It is a patch window item, and the reason to move quickly is the leader-election bypass rather than any evidence of current attacks.

References

Related Tools

Try these companion tools on DevStackIO Tools:

  • hash generator — generate database credential hashes for watchdog authentication.