GHSA-VQ9P-W6WV-CR25
Vulnerability from github – Published: 2026-11-12 20:46 – Updated: 2026-11-12 20:46Summary
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.1or::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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.10.1"
},
"package": {
"ecosystem": "Go",
"name": "github.com/pgEdge/control-plane"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-125323"
],
"database_specific": {
"cwe_ids": [
"CWE-1188",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-12T20:46:03Z",
"nvd_published_at": "2026-11-10T18:17:33Z",
"severity": "HIGH"
},
"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 \u2014 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** \u2014 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** \u2014 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 \u2013 v0.8.1.** An operator could take the authentication files out of Patroni\u0027s 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 \u2013 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 \u2013 v0.10.1 should upgrade to v0.11.0.",
"id": "GHSA-vq9p-w6wv-cr25",
"modified": "2026-11-12T20:46:03Z",
"published": "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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "pgEdge Control Plane generates pg_hba.conf with trust authentication for local and loopback connections"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.