Pgpool Global Development Group shipped security releases on October 1 for every maintained branch of Pgpool-II: 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21. Seven CVEs are fixed, and six of them live in watchdog — the subsystem that holds quorum, owns the delegate IP, and decides when your backend gets promoted. If Pgpool-II sits in your failover path, this is a patch-today release, not a next-maintenance-window release.

The seven CVEs, sorted by what they break

Per the release announcement, six vulnerabilities are remote memory-safety or authentication failures in watchdog message handling:

• CVE-2026-92867 — a malformed watchdog message during failover lets an attacker write an arbitrary 32-bit value to an arbitrary memory address.
• CVE-2026-92869 — watchdog message processing writes past the bounds of fixed-size arrays.
• CVE-2026-92870 — failover messages allow arbitrary-length writes that corrupt the stack and crash the process.
• CVE-2026-92871 — NULL pointer dereference in watchdog inter-node authentication when crafted messages omit auth data while an auth key is configured.
• CVE-2026-92872 — information disclosure in the heartbeat receiver process.
• CVE-2026-92873 — watchdog promotion processing lets an attacker bypass authentication-key checks entirely and promote a watchdog node of their choosing to leader.

The seventh is on the client-facing side: CVE-2026-92868 mishandles NUL bytes in the Common Name of a client X.509 certificate, allowing a malicious client to connect as another user without a password. If you use certificate authentication for client connections, that one applies even without watchdog.

Why a watchdog CVE is an availability CVE

Watchdog is the election layer. The leader node owns the virtual IP that applications connect to, and election results drive backend promotion through the failover command. So the exploit list above maps directly onto the two failure modes Postgres HA designs exist to prevent:

• Crash loops. 92869 and 92870 corrupt memory in the process that must stay up to run elections. A watchdog that crashes under load is a cluster that cannot decide who is primary.
• Hijacked elections. 92873 skips the auth key and installs an attacker’s choice as leader. Combine that with the arbitrary-write primitive in 92867 and the information leak in 92872, and a host that can reach port 9000 has a path to split-brain: a VIP that moves to an isolated Pgpool-II node, with clients writing through a stale view of the primary.

The quorum controls that guard against split-brain — failover_require_consensus and failover_when_quorum_exists, both on by default — run over the same watchdog message bus these CVEs attack.

Are you exposed? A five-minute check

1. Is watchdog on? use_watchdog defaults to off. A single Pgpool-II instance used purely as a pooler is not exposed to the watchdog CVEs.
2. Is the watchdog port reachable beyond your peers? The watchdog port defaults to 9000 (wd_port0), separate from Pgpool-II’s client port 9999. Check what is listening and who can reach it: ss -lntp | grep -E '9000|9999'.
3. Is the auth key set? wd_authkey defaults to empty, which disables watchdog authentication. Two of these CVEs (92871, 92873) concern that authentication path; an empty key is the worst case.
4. Do you use certificate auth for client connections? If yes, 92868 applies regardless of watchdog.

Patch without losing quorum

Every watchdog parameter in this article is marked server-start only in the watchdog reference, so hardening requires a restart of the Pgpool-II process — a reload will not do. In a three-node watchdog cluster, one node down keeps quorum; two nodes down does not. Restart strictly one node at a time and verify before moving on.

# 0) baseline: who is leader, is quorum present
pcp_watchdog_info -h 10.20.0.11 -p 9898 -U pgpool -v

# 1) one node only: stop, update, confirm the new version, start
sudo systemctl stop pgpool-II
sudo dnf update -y pgpool-II        # apt: apt install --only-upgrade pgpool-II
pgpool --version                    # must report 4.7.3 / 4.6.8 / 4.5.13 / 4.4.18 / 4.3.21
sudo systemctl start pgpool-II

# 2) quorum and leader must be healthy again before the next node
pcp_watchdog_info -h 10.20.0.11 -p 9898 -U pgpool -v | grep -i quorum
psql -h 10.20.0.100 -p 9999 -c "show pool_nodes;"

If the leader moves during a controlled, one-node-at-a-time restart, your lifecheck or network settings are too twitchy — fix that before you need real failover. The pcp_watchdog_info output also gives you the per-node state and membership you need in the change ticket.

Harden the watchdog plane in the same window

# ---- watchdog plane: ops NIC only, authenticated ----------------
use_watchdog      = on
wd_listen_address = '10.20.0.11'      # never 0.0.0.0 on a shared network
wd_port0          = 9000
pgpool_port0      = 9999
wd_authkey        = 'shared-secret-32-plus-random-characters'
trusted_servers   = '10.20.0.1,10.20.0.2'   # routers/upstream, not Postgres
delegate_ip       = '10.20.0.100'
if_up_cmd         = '/usr/bin/sudo /sbin/ip addr add $_IP_$/24 dev eth0 label eth0:0'
if_down_cmd       = '/usr/bin/sudo /sbin/ip addr del $_IP_$/24 dev eth0'
arping_cmd        = '/usr/bin/sudo /usr/sbin/arping -U $_IP_$ -w 1 -I eth0'
wd_lifecheck_method = 'heartbeat'
wd_heartbeat_deadtime = 30

Then close the network path: only peer Pgpool-II hosts should be able to open port 9000, and only the VIP (or the pooler port on a private segment) should be reachable by applications. wd_authkey authenticates watchdog packets; it does not encrypt them, so keep the bus on a private interface. This is the same trust-boundary argument as locking down the replication port — the middleware is part of the data path.

What to watch afterwards

• Alert on pcp_watchdog_info reporting QUORUM ABSENT or any unexpected leader change.
• Pre-patch, malformed watchdog messages can show up as parse errors or odd crashes in the Pgpool-II log; those lines are worth keeping for incident review.
• Confirm clients land on the expected primary after any failover event, using show pool_nodes or pcp_node_info.

Houston note

Most local deployments I see run Pgpool-II in front of a Patroni-managed pair for energy-trading or clinical workloads, where the VIP is baked into connection strings. Those teams should treat 92873 as the priority: a hijacked leader on the wrong side of a partition is the one failure that produces a wrong-node write. If you are still on 4.2.x or earlier, you are no longer on the fixed-branch list, so plan a branch upgrade rather than a one-line patch — and if you would rather drop the extra hop, our walkthrough of Patroni and automatic failover covers the alternative architecture.

Binaries and source are on the Pgpool-II downloads page; the fixes are summarised in the project’s release notes. Patch the middleware you forgot was in the failover path.