Pgpool-II client certificate validation bypass: what CVE-2026-92868 changes

Pgpool Global Development Group published a batch of fixes for Pgpool-II on 29 September 2026, and JVN#22475874 collects seven CVEs in a single notice. The item that deserves attention first is CVE-2026-92868, an improper certificate validation flaw the advisory ties to client certificate authentication bypass. Affected branches run from 3.5.x up to 4.7.2, so a large share of installed clusters falls inside the range.

What the advisory describes

The notice covers Pgpool-II versions 4.7.0 to 4.7.2, 4.6.0 to 4.6.7, 4.5.0 to 4.5.12, 4.4.0 to 4.4.17 and 4.3.0 to 4.3.20. Six of the seven CVEs also apply to every release in the 3.5.x through 4.2.x series. CVE-2026-92868 has its own shorter range starting at 4.0.x. The fixed releases are 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21.

JPCERT/CC coordinated the report. Emond Papegaaij of Topicus Security reported the issues to the project, and the vendor and JPCERT/CC published matching advisories for users.

Where the certificate validation flaw sits

CVE-2026-92868 is classified as improper certificate validation, CWE-295. The CVSS v4 base score is 6.9 and the v3 score is 6.5. The vector carries no privilege requirement and no user interaction: AV:N/AC:L/PR:N/UI:N.

That combination describes a specific failure. A client certificate check exists to bind a connection to a key that has already been validated. When the check itself is implemented incorrectly, the validation step becomes the weak point instead of the certificate. The advisory does not name the subsystem involved, so the practical severity for any given cluster depends on whether TLS with client certificate authentication is enabled there. A deployment that never asks clients for certificates has little to lose from this particular CVE.

The other six CVEs in the same release

Seven CVEs shipped in one advisory, and four of them are memory safety issues.

Two of the seven need a foothold before they can be triggered. The vectors for CVE-2026-92867 and CVE-2026-92869 list PR:L, meaning a low privileged position somewhere on the network path. The remaining five are reachable without credentials.

Which deployments are in range

The affected ranges cover five maintained branches and a long stretch of retired ones. An inventory check is harder than it sounds. Distributions and container images sometimes package an older minor release than the one administrators remember installing, and Pgpool-II is often deployed as a sidecar that nobody tracks in the asset database. Reading the version from the running binary rather than from a package listing avoids that mismatch.

The 3.5.x through 4.2.x series appear in the advisory but no longer receive fixes. Support for those branches has ended, and the advisory recommends moving to a maintained release rather than waiting for a backport that will not come.

Exposure measured through ZoomEye

A ZoomEye query for the product fingerprint app="Pgpool-II" returned 101 matching instances when it ran on 29 September 2026. The CVE-specific query vul.cve="CVE-2026-92868" returned zero, which is normal shortly after disclosure because that field depends on fingerprint data catching up with the advisory.

The 101 figure counts Pgpool-II assets that ZoomEye can see on the public internet. It does not prove those instances are unpatched, and it says nothing about clusters reachable only from inside a private network. Treat it as a scale estimate for internet-facing middleware, not as a vulnerability count.

Impact

Ranking the seven by operational consequence puts the code execution case first and the watchdog issue second. CVE-2026-92867 allows arbitrary code execution with a low privileged starting point, which on a connection pooler means an attacker lands inside the component that holds database credentials and routes every query. CVE-2026-92873 allows an arbitrary watchdog node to be promoted to leader, and the leader in a watchdog cluster coordinates failover decisions, so a rogue node in that role can steer how the cluster responds to failures.

The remaining five produce abnormal process termination, watchdog termination, a cluster information leak, or the certificate bypass. Each is serious in its own way, but none of them hands over the same level of control.

Remediation and mitigations

The advisory recommends updating to the latest version. Fixed releases are Pgpool-II 4.7.3, 4.6.8, 4.5.13, 4.4.18 and 4.3.21, one per maintained branch. Clusters on 4.2.x or older need a branch upgrade because those versions will not receive patches.

After an upgrade, confirming the running version on every node is worth the extra step, since a partial rollout leaves the cluster with mixed versions. Where the update has to wait, the practical interim control is to restrict who can reach the Pgpool-II listener and to check recent logs for unexpected client connections. The advisory itself only recommends updating, so any additional control is an operational judgement rather than vendor guidance.

References

JVN#22475874: Multiple vulnerabilities in Pgpool-II

Pgpool Global Development Group