Answer in brief
CVE-2026-125323 records a High severity (CVSS 7.8) vulnerability in pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections. The current sources do not mark it as known exploited. The current feed maps pgEdge/control-plane (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps pgEdge/control-plane (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| pgEdge/control-planegeneric | <0.11.0 | 0.11.0 |
Published upstream
Nov 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 10, 2026
pgEdge Control Plane is a distributed application for managing and orchestrating Postgres databases across multiple hosts. From 0.1.0 to 0.10.1, generated pg_hba.conf files began with hard-coded trust entries for Unix-socket and loopback connections. Because PostgreSQL evaluates the file from top to bottom, those entries also preempted operator-supplied rules in the pg_hba_conf field. Under the systemd orchestrator, any unprivileged operating-system account on a database host could authenticate as any PostgreSQL role, including the superuser, without credentials and obtain full control of the host's databases. Under Docker Swarm, reaching the container-local socket or loopback interface required code execution inside the database container. Publishing the PostgreSQL port to the host did not expose these trust rules because host connections did not appear to originate from 127.0.0.1 or ::1. This issue is fixed in version 0.11.0.
Quoted source text, attributed separately from HOL analysis.