{"id":"CVE-2026-125323","aliases":["EUVD-2026-121705","GHSA-vq9p-w6wv-cr25"],"status":"published","title":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","description":"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.","severity":{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00121,"percentile":0.01953,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1188","CWE-306"],"published":"2026-11-10T17:52:28Z","modified":"2026-11-12T22:18:51Z","fixes":[{"ecosystem":"Go","package":"github.com/pgEdge/control-plane","fixed_in":["0.11.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/pgEdge/control-plane","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.10.1"},{"fixed":"0.11.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/pgEdge/control-plane","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}]}],"products":[{"vendor":"pgedge","product":"control-plane"}],"references":[{"url":"https://github.com/pgEdge/control-plane/security/advisories/GHSA-vq9p-w6wv-cr25","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/pgEdge/control-plane/pull/470","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pgEdge/control-plane/commit/88659f7388fc6c86125e60475aa83810171145b7","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/pgEdge/control-plane/blob/main/changes/v0.11.0.md","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/pgEdge/control-plane/releases/tag/v0.11.0","tags":["x_refsource_MISC","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-125323","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-vq9p-w6wv-cr25"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/125xxx/CVE-2026-125323.json","tags":["advisory"]},{"url":"https://github.com/pgEdge/control-plane","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-125323","title":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","description":"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.","status":"published","published":"2026-11-10T17:52:28.455Z","modified":"2026-11-12T18:02:47.992Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-306","CWE-1188"],"updated_at":"2026-11-10T18:39:47.416646Z"}],"euvd":[{"id":"EUVD-2026-121705","description":"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.","status":"published","published":"2026-11-10T17:52:28Z","modified":"2026-11-12T18:02:47Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-12T23:36:14.96932Z"}],"ghsa":[{"id":"GHSA-vq9p-w6wv-cr25","title":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","description":"### 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.","status":"published","published":"2026-11-12T20:46:03Z","modified":"2026-11-12T20:46:05Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-306","CWE-1188"],"updated_at":"2026-11-12T21:13:23.478099Z"}],"nvd":[{"id":"CVE-2026-125323","description":"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.","status":"published","published":"2026-11-10T18:17:33.703Z","modified":"2026-11-12T22:18:51.47Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-306","CWE-1188"],"updated_at":"2026-11-10T20:21:09.613171Z"}],"osv":[{"id":"CVE-2026-125323","title":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","description":"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.","status":"published","published":"2026-11-10T17:52:28.455Z","modified":"2026-11-13T10:30:54.580121919Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-1188","CWE-306"],"updated_at":"2026-11-12T03:30:55.144331Z"},{"id":"GHSA-vq9p-w6wv-cr25","title":"pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections","description":"### 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.","status":"published","published":"2026-11-12T20:46:03Z","modified":"2026-11-12T21:00:03.623455832Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-1188","CWE-306"],"updated_at":"2026-11-12T21:15:34.287192Z"}]}}