{"id":"GHSA-vq9p-w6wv-cr25","summary":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","details":"### Summary\n\nEvery `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.\n\n### Details\n\nThe generated file opens with the following six entries:\n\n```\nlocal   all         all                     trust\nhost    all         all     127.0.0.1/32    trust\nhost    all         all     ::1/128         trust\nlocal   replication all                     trust\nhost    replication all     127.0.0.1/32    trust\nhost    replication all     ::1/128         trust\n```\n\nPostgres 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.\n\nBoth supported orchestrators emit these entries, but exposure differs by deployment model:\n\n* **systemd** — the database runs on a shared multi-user host. Any local account\n  on that host can connect as the Postgres superuser. This is the\n  higher-severity case and the one the CVSS score below reflects.\n* **Docker Swarm** — the Unix socket and the loopback interface belong to the\n  Postgres container, so reaching these entries requires code execution inside\n  that container. Publishing the Postgres port to the host does not change this:\n  such connections are not seen by Postgres as originating from `127.0.0.1` or\n  `::1`, so they do not match the entries above. The practical exposure is\n  correspondingly narrower.\n\nAn 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.\n\n### Impact\n\nAn 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.\n\n### Affected versions\n\npgEdge Control Plane v0.1.0 through v0.10.1, inclusive.\n\n### Patches\n\nFixed 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.\n\n### Workarounds\n\nThe available mitigation differs by version, and no mitigation is complete on current releases.\n\n**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.\n\n**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.","aliases":["CVE-2026-125323"],"modified":"2026-11-12T21:00:03.623455832Z","published":"2026-11-12T20:46:03Z","database_specific":{"nvd_published_at":"2026-11-10T18:17:33Z","cwe_ids":["CWE-1188","CWE-306"],"severity":"HIGH","github_reviewed":true,"github_reviewed_at":"2026-11-12T20:46:03Z"},"references":[{"type":"WEB","url":"https://github.com/pgEdge/control-plane/security/advisories/GHSA-vq9p-w6wv-cr25"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-125323"},{"type":"WEB","url":"https://github.com/pgEdge/control-plane/pull/470"},{"type":"WEB","url":"https://github.com/pgEdge/control-plane/commit/88659f7388fc6c86125e60475aa83810171145b7"},{"type":"PACKAGE","url":"https://github.com/pgEdge/control-plane"},{"type":"WEB","url":"https://github.com/pgEdge/control-plane/blob/main/changes/v0.11.0.md"},{"type":"WEB","url":"https://github.com/pgEdge/control-plane/releases/tag/v0.11.0"}],"affected":[{"package":{"name":"github.com/pgEdge/control-plane","ecosystem":"Go","purl":"pkg:golang/github.com/pgEdge/control-plane"},"ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}],"database_specific":{"last_known_affected_version_range":"\u003c= 0.10.1","source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/11/GHSA-vq9p-w6wv-cr25/GHSA-vq9p-w6wv-cr25.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}