CVE-2026-125323

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.

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.

Summary

Every pg_hba.conf generated by the pgEdge Control Plane begins with a hard-coded block of trust entries covering Unix-socket and loopback connections. Any operating-system account that can reach the Postgres socket or the loopback interface on a database host can authenticate as any Postgres role, including the superuser, without presenting a credential.

Details

The generated file opens with the following six entries:

local   all         all                     trust
host    all         all     127.0.0.1/32    trust
host    all         all     ::1/128         trust
local   replication all                     trust
host    replication all     127.0.0.1/32    trust
host    replication all     ::1/128         trust

Postgres evaluates pg_hba.conf top-down and stops at the first matching rule. Because these entries are emitted at the top of the file, they also pre-empt every rule below them — including entries supplied by an operator through the pg_hba_conf field of a database node specification, which are appended lower in the file and are therefore never reached for local or loopback connections.

Both supported orchestrators emit these entries, but exposure differs by deployment model:

• systemd — the database runs on a shared multi-user host. Any local account on that host can connect as the Postgres superuser. This is the higher-severity case and the one the CVSS score below reflects.
• Docker Swarm — the Unix socket and the loopback interface belong to the Postgres container, so reaching these entries requires code execution inside that container. Publishing the Postgres port to the host does not change this: such connections are not seen by Postgres as originating from 127.0.0.1 or ::1, so they do not match the entries above. The practical exposure is correspondingly narrower.

An operator who verifies their own deployment can confirm the issue by inspecting the generated pg_hba.conf on a database node for the entries above.

Impact

An unprivileged local operating-system account on an affected database host obtains full control of every Postgres database on that host: read of all data, modification or destruction of all data, and any action available to a Postgres superuser. Under the systemd orchestrator this converts any local account into a database superuser with no additional prerequisites.

Affected versions

pgEdge Control Plane v0.1.0 through v0.10.1, inclusive.

Patches

Fixed in v0.11.0. Generated pg_hba.conf files no longer contain trust entries, and operator-supplied local authentication rules take effect. Upgrading to v0.11.0 or later is the recommended and, on v0.9.0 and later, the only complete remedy.

Workarounds

The available mitigation differs by version, and no mitigation is complete on current releases.

v0.1.0 – v0.8.1. An operator could take the authentication files out of Patroni's control entirely: copy the generated pg_hba.conf and pg_ident.conf, edit the copies, and point the hba_file and ident_file settings at them through node-level postgresql_conf. This is effective but must be repeated per instance, including for every node added afterwards.

v0.9.0 – v0.10.1. The above no longer applies. API validation rejects the hba_file and ident_file settings, and entries supplied through the pg_hba_conf specification array are appended below the hard-coded block rather than overriding it, so they do not take effect for local or loopback connections. The only partial mitigation available is to restrict the Unix socket: set unix_socket_permissions to 0700, or to 0770 with the intended accounts placed in the postgres group. This closes the socket path only. No supported configuration closes the loopback path on these versions. Operators on v0.9.0 – v0.10.1 should upgrade to v0.11.0.

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.

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.

Summary

Every pg_hba.conf generated by the pgEdge Control Plane begins with a hard-coded block of trust entries covering Unix-socket and loopback connections. Any operating-system account that can reach the Postgres socket or the loopback interface on a database host can authenticate as any Postgres role, including the superuser, without presenting a credential.

Details

The generated file opens with the following six entries:

local   all         all                     trust
host    all         all     127.0.0.1/32    trust
host    all         all     ::1/128         trust
local   replication all                     trust
host    replication all     127.0.0.1/32    trust
host    replication all     ::1/128         trust

Postgres evaluates pg_hba.conf top-down and stops at the first matching rule. Because these entries are emitted at the top of the file, they also pre-empt every rule below them — including entries supplied by an operator through the pg_hba_conf field of a database node specification, which are appended lower in the file and are therefore never reached for local or loopback connections.

Both supported orchestrators emit these entries, but exposure differs by deployment model:

• systemd — the database runs on a shared multi-user host. Any local account on that host can connect as the Postgres superuser. This is the higher-severity case and the one the CVSS score below reflects.
• Docker Swarm — the Unix socket and the loopback interface belong to the Postgres container, so reaching these entries requires code execution inside that container. Publishing the Postgres port to the host does not change this: such connections are not seen by Postgres as originating from 127.0.0.1 or ::1, so they do not match the entries above. The practical exposure is correspondingly narrower.

An operator who verifies their own deployment can confirm the issue by inspecting the generated pg_hba.conf on a database node for the entries above.

Impact

An unprivileged local operating-system account on an affected database host obtains full control of every Postgres database on that host: read of all data, modification or destruction of all data, and any action available to a Postgres superuser. Under the systemd orchestrator this converts any local account into a database superuser with no additional prerequisites.

Affected versions

pgEdge Control Plane v0.1.0 through v0.10.1, inclusive.

Patches

Fixed in v0.11.0. Generated pg_hba.conf files no longer contain trust entries, and operator-supplied local authentication rules take effect. Upgrading to v0.11.0 or later is the recommended and, on v0.9.0 and later, the only complete remedy.

Workarounds

The available mitigation differs by version, and no mitigation is complete on current releases.

v0.1.0 – v0.8.1. An operator could take the authentication files out of Patroni's control entirely: copy the generated pg_hba.conf and pg_ident.conf, edit the copies, and point the hba_file and ident_file settings at them through node-level postgresql_conf. This is effective but must be repeated per instance, including for every node added afterwards.

v0.9.0 – v0.10.1. The above no longer applies. API validation rejects the hba_file and ident_file settings, and entries supplied through the pg_hba_conf specification array are appended below the hard-coded block rather than overriding it, so they do not take effect for local or loopback connections. The only partial mitigation available is to restrict the Unix socket: set unix_socket_permissions to 0700, or to 0770 with the intended accounts placed in the postgres group. This closes the socket path only. No supported configuration closes the loopback path on these versions. Operators on v0.9.0 – v0.10.1 should upgrade to v0.11.0.