Pgpool-II patches certificate validation bypass CVE-2026-92868 in seven-CVE security release

The Pgpool Global Development Group published patched Pgpool-II releases on 29 September 2026, closing seven vulnerabilities gathered under the coordinated advisory JVN#22475874. The entry drawing the most attention is CVE-2026-92868, an improper certificate validation flaw that the advisory ties to bypassing client certificate authentication. According to a dev.to write-up on the release, Emond Papegaaij of Topicus Security reported the issues and JPCERT/CC coordinated the disclosure between researcher and vendor.

Which versions are affected

The advisory names five maintained branches: 4.7.0 through 4.7.2, 4.6.0 through 4.6.7, 4.5.0 through 4.5.12, 4.4.0 through 4.4.17, and 4.3.0 through 4.3.20. Fixes land in 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21, one release per branch. Six of the seven CVEs also reach into the retired 3.5.x through 4.2.x series, while the certificate bug has a shorter history, starting at 4.0.x. Support for the older series has ended, so the dev.to article stresses that clusters there need a branch upgrade rather than a backport that will never arrive.

The certificate bypass in detail

CVE-2026-92868 is classified as CWE-295, improper certificate validation, with a CVSS v4 base score of 6.9 and a v3 score of 6.5. Its vector is network-reachable with low attack complexity and requires neither privileges nor user interaction. Conceptually, a client certificate check exists to tie an incoming connection to a key that has already been vetted; when the check itself is written incorrectly, the validation step becomes the weak link instead of the certificate. The advisory does not identify the subsystem involved, so the dev.to author argues that real-world severity hinges on whether TLS client certificate authentication is actually enabled. A deployment that never asks clients for certificates has little to lose from this specific flaw.

The other six CVEs

CVE	Weakness	CVSS v4 / v3	Advisory impact
CVE-2026-92867	Out-of-bounds write (CWE-787)	8.7 / 8.8	Process termination and arbitrary code execution
CVE-2026-92869	Out-of-bounds write (CWE-787)	7.1 / 6.5	Abnormal process termination
CVE-2026-92870	Stack buffer overflow (CWE-121)	8.7 / 7.5	Abnormal process termination
CVE-2026-92871	NULL pointer dereference (CWE-476)	8.7 / 7.5	Termination of the watchdog process
CVE-2026-92872	Sensitive data written to logs (CWE-532)	5.3 / 4.3	Cluster information leak
CVE-2026-92873	Incorrect authentication algorithm (CWE-303)	6.9 / 7.3	Arbitrary watchdog node promoted to leader

Two of the seven, CVE-2026-92867 and CVE-2026-92869, require a low-privileged foothold on the network path before they can be triggered; the other five are reachable without credentials. Ranked by consequence, the dev.to analysis puts CVE-2026-92867 first, because code execution on a connection pooler places an attacker inside the component that stores database credentials and forwards every query. CVE-2026-92873 follows: the watchdog leader coordinates failover decisions, so a rogue node promoted into that role can steer how the cluster responds to failures.

How much is exposed

A ZoomEye search for the fingerprint app="Pgpool-II" returned 101 internet-visible instances when it ran on 29 September 2026. A query tagged to the new CVE returned zero matches, which the article attributes to fingerprint data needing time to catch up with a fresh disclosure. The 101 figure neither proves those instances are unpatched nor captures clusters reachable only inside private networks, so it is best read as a rough scale estimate for internet-facing middleware.

Why it matters

Pgpool-II sits directly in the data path between applications and PostgreSQL: it holds database credentials, pools connections and routes every query. A batch that combines a network-reachable authentication bypass with a potential code execution flaw and a way to manipulate watchdog leadership touches the three things operators care most about — who can connect, what runs on the box, and how failover behaves. Client certificate authentication is typically deployed precisely because the surrounding network is not trusted, so a silent bypass of that check removes a control many teams assume is holding. The inventory problem the article highlights is real as well, since poolers often run as untracked container sidecars packaging older minor releases than anyone remembers installing.

What operators should do

Upgrade every node to the fixed release for its branch, then confirm the version by reading the running binary rather than a package listing, since distributions and images sometimes lag behind what administrators believe is installed, and a partial rollout leaves mixed versions behind. Clusters on 4.2.x or older must move to a maintained branch. Where the update has to wait, the suggested interim measures are restricting who can reach the Pgpool-II listener and reviewing recent logs for unexpected client connections, with the caveat that the vendor advisory itself only recommends updating, so anything further is operational judgement rather than official guidance.