Vulnerability-Lookup

CVE-2026-17349 (GCVE-0-2026-17349)

Vulnerability from cvelistv5 – Published: 2026-07-31 15:59 – Updated: 2026-08-01 03:56

Title

pgAdmin 4: Adhoc server clone leaks another user's stored database credentials and ownership to a non-owner

Summary

/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own. Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials. This issue affects pgAdmin 4: from 9.0 before 9.17.

Severity

9.6 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

9.3 (Critical)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator (v2.0.3)

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key
CWE-522 - Insufficiently Protected Credentials

Assigner

PostgreSQL

References

3 references

URL	Tags
https://github.com/pgadmin-org/pgadmin4/issues/10200	issue-tracking
https://github.com/pgadmin-org/pgadmin4/commit/a7…	related
https://github.com/pgadmin-org/pgadmin4/commit/64…	patch

Impacted products

1 product

Vendor	Product	Version
pgadmin.org	pgAdmin 4	Affected: 9.0 , < 9.17 (custom)

Credits

Ashesh Vashi <ashesh.vashi@enterprisedb.com> Ashesh Vashi <ashesh.vashi@enterprisedb.com> Kundan Sable <kundan.sable@enterprisedb.com>

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-17349",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-31T00:00:00+00:00",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-01T03:56:26.176Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Workspaces"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/workspaces/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.17",
              "status": "affected",
              "version": "9.0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user\u0027s (in practice, typically an administrator\u0027s) shared server, the clone inherited that user\u0027s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user\u0027s stored database password on the non-owner\u0027s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.\n\nFix forces the cloned adhoc record\u0027s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server\u0027s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user\u0027s shared server persists a row owned by the caller, not shared, and without the source\u0027s stored credentials.\n\nThis issue affects pgAdmin 4: from 9.0 before 9.17."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.6,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Threat model: an authenticated, low-privilege pgAdmin user who knows or can enumerate the server id of another user\u0027s (e.g. an administrator\u0027s) shared server row triggers an adhoc connect against it. No special privilege beyond ordinary authenticated access is needed, and no interaction from the victim is required. Scope is Changed: the attacker\u0027s own pgAdmin authorization does not itself grant use of the source user\u0027s stored database credentials, so gaining and using those credentials crosses into another user\u0027s security authority -- specifically the database privileges the source user\u0027s stored credentials confer, which may substantially exceed the attacker\u0027s own. Confidentiality and Integrity are High because the attacker obtains a working, reusable database credential and can use it to read/write whatever the source user\u0027s database role permits. Availability is None: the leak itself does not directly cause denial of service."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 9.3,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry: an authenticated low-privilege user obtains another user\u0027s stored database credential via server cloning, without any interaction from the victim. VC:H/VI:H for pgAdmin\u0027s own scope (the leaked credential itself); SC:H/SI:H because the credential is then usable against the underlying database server, a subsequent system whose privileges may substantially exceed the attacker\u0027s own. VA:N/SA:N since the leak alone does not cause denial of service."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639 Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-31T15:59:47.841Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10200"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/a7e74a6ed685bc34e1f77a8b6a94d00fa3dff815"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Adhoc server clone leaks another user\u0027s stored database credentials and ownership to a non-owner"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-17349",
    "datePublished": "2026-07-31T15:59:47.841Z",
    "dateReserved": "2026-07-25T02:52:56.082Z",
    "dateUpdated": "2026-08-01T03:56:26.176Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-17349",
      "date": "2026-08-01",
      "epss": "0.003",
      "percentile": "0.22366"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-17349\",\"sourceIdentifier\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\",\"published\":\"2026-07-31T16:16:59.480\",\"lastModified\":\"2026-08-01T05:16:55.533\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user\u0027s (in practice, typically an administrator\u0027s) shared server, the clone inherited that user\u0027s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user\u0027s stored database password on the non-owner\u0027s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.\\n\\nFix forces the cloned adhoc record\u0027s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server\u0027s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user\u0027s shared server persists a row owned by the caller, not shared, and without the source\u0027s stored credentials.\\n\\nThis issue affects pgAdmin 4: from 9.0 before 9.17.\"}],\"affected\":[{\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\",\"affectedData\":[{\"vendor\":\"pgadmin.org\",\"product\":\"pgAdmin 4\",\"defaultStatus\":\"unaffected\",\"modules\":[\"Workspaces\"],\"programFiles\":[\"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/workspaces/__init__.py\"],\"repo\":\"https://github.com/pgadmin-org/pgadmin4\",\"versions\":[{\"version\":\"9.0\",\"lessThan\":\"9.17\",\"versionType\":\"custom\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV40\":[{\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"4.0\",\"vectorString\":\"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X\",\"baseScore\":9.3,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"attackRequirements\":\"NONE\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"vulnConfidentialityImpact\":\"HIGH\",\"vulnIntegrityImpact\":\"HIGH\",\"vulnAvailabilityImpact\":\"NONE\",\"subConfidentialityImpact\":\"HIGH\",\"subIntegrityImpact\":\"HIGH\",\"subAvailabilityImpact\":\"NONE\",\"exploitMaturity\":\"NOT_DEFINED\",\"confidentialityRequirement\":\"NOT_DEFINED\",\"integrityRequirement\":\"NOT_DEFINED\",\"availabilityRequirement\":\"NOT_DEFINED\",\"modifiedAttackVector\":\"NOT_DEFINED\",\"modifiedAttackComplexity\":\"NOT_DEFINED\",\"modifiedAttackRequirements\":\"NOT_DEFINED\",\"modifiedPrivilegesRequired\":\"NOT_DEFINED\",\"modifiedUserInteraction\":\"NOT_DEFINED\",\"modifiedVulnConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedVulnIntegrityImpact\":\"NOT_DEFINED\",\"modifiedVulnAvailabilityImpact\":\"NOT_DEFINED\",\"modifiedSubConfidentialityImpact\":\"NOT_DEFINED\",\"modifiedSubIntegrityImpact\":\"NOT_DEFINED\",\"modifiedSubAvailabilityImpact\":\"NOT_DEFINED\",\"Safety\":\"NOT_DEFINED\",\"Automatable\":\"NOT_DEFINED\",\"Recovery\":\"NOT_DEFINED\",\"valueDensity\":\"NOT_DEFINED\",\"vulnerabilityResponseEffort\":\"NOT_DEFINED\",\"providerUrgency\":\"NOT_DEFINED\"}}],\"cvssMetricV31\":[{\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N\",\"baseScore\":9.6,\"baseSeverity\":\"CRITICAL\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.1,\"impactScore\":5.8}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-07-31T00:00:00+00:00\",\"id\":\"CVE-2026-17349\",\"options\":[{\"exploitation\":\"none\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"total\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-522\"},{\"lang\":\"en\",\"value\":\"CWE-639\"}]}],\"references\":[{\"url\":\"https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779\",\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\"},{\"url\":\"https://github.com/pgadmin-org/pgadmin4/commit/a7e74a6ed685bc34e1f77a8b6a94d00fa3dff815\",\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\"},{\"url\":\"https://github.com/pgadmin-org/pgadmin4/issues/10200\",\"source\":\"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-17349\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-07-31T17:21:38.095146Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-07-31T17:21:46.538Z\"}}], \"cna\": {\"title\": \"pgAdmin 4: Adhoc server clone leaks another user\u0027s stored database credentials and ownership to a non-owner\", \"source\": {\"discovery\": \"INTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e\"}, {\"lang\": \"en\", \"type\": \"remediation developer\", \"value\": \"Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e\"}, {\"lang\": \"en\", \"type\": \"remediation reviewer\", \"value\": \"Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e\"}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV3_1\": {\"scope\": \"CHANGED\", \"version\": \"3.1\", \"baseScore\": 9.6, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"CRITICAL\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"Threat model: an authenticated, low-privilege pgAdmin user who knows or can enumerate the server id of another user\u0027s (e.g. an administrator\u0027s) shared server row triggers an adhoc connect against it. No special privilege beyond ordinary authenticated access is needed, and no interaction from the victim is required. Scope is Changed: the attacker\u0027s own pgAdmin authorization does not itself grant use of the source user\u0027s stored database credentials, so gaining and using those credentials crosses into another user\u0027s security authority -- specifically the database privileges the source user\u0027s stored credentials confer, which may substantially exceed the attacker\u0027s own. Confidentiality and Integrity are High because the attacker obtains a working, reusable database credential and can use it to read/write whatever the source user\u0027s database role permits. Availability is None: the leak itself does not directly cause denial of service.\"}]}, {\"format\": \"CVSS\", \"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 9.3, \"baseSeverity\": \"CRITICAL\", \"vectorString\": \"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"Same reasoning as the CVSS 3.1 entry: an authenticated low-privilege user obtains another user\u0027s stored database credential via server cloning, without any interaction from the victim. VC:H/VI:H for pgAdmin\u0027s own scope (the leaked credential itself); SC:H/SI:H because the credential is then usable against the underlying database server, a subsequent system whose privileges may substantially exceed the attacker\u0027s own. VA:N/SA:N since the leak alone does not cause denial of service.\"}]}], \"affected\": [{\"repo\": \"https://github.com/pgadmin-org/pgadmin4\", \"vendor\": \"pgadmin.org\", \"modules\": [\"Workspaces\"], \"product\": \"pgAdmin 4\", \"versions\": [{\"status\": \"affected\", \"version\": \"9.0\", \"lessThan\": \"9.17\", \"versionType\": \"custom\"}], \"programFiles\": [\"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/workspaces/__init__.py\"], \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://github.com/pgadmin-org/pgadmin4/issues/10200\", \"tags\": [\"issue-tracking\"]}, {\"url\": \"https://github.com/pgadmin-org/pgadmin4/commit/a7e74a6ed685bc34e1f77a8b6a94d00fa3dff815\", \"tags\": [\"related\"]}, {\"url\": \"https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779\", \"tags\": [\"patch\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user\u0027s (in practice, typically an administrator\u0027s) shared server, the clone inherited that user\u0027s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user\u0027s stored database password on the non-owner\u0027s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.\\n\\nFix forces the cloned adhoc record\u0027s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server\u0027s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user\u0027s shared server persists a row owned by the caller, not shared, and without the source\u0027s stored credentials.\\n\\nThis issue affects pgAdmin 4: from 9.0 before 9.17.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-639\", \"description\": \"CWE-639 Authorization Bypass Through User-Controlled Key\"}, {\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-522\", \"description\": \"CWE-522 Insufficiently Protected Credentials\"}]}], \"providerMetadata\": {\"orgId\": \"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\", \"shortName\": \"PostgreSQL\", \"dateUpdated\": \"2026-07-31T15:59:47.841Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-17349\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-01T03:56:26.176Z\", \"dateReserved\": \"2026-07-25T02:52:56.082Z\", \"assignerOrgId\": \"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\", \"datePublished\": \"2026-07-31T15:59:47.841Z\", \"assignerShortName\": \"PostgreSQL\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-P547-RJMG-JQR4

Vulnerability from github – Published: 2026-07-31 18:32 – Updated: 2026-07-31 18:32

Details

Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials.

This issue affects pgAdmin 4: from 9.0 before 9.17.

Severity

9.6 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

9.3 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-17349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-31T16:16:59Z",
    "severity": "CRITICAL"
  },
  "details": "/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user\u0027s (in practice, typically an administrator\u0027s) shared server, the clone inherited that user\u0027s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user\u0027s stored database password on the non-owner\u0027s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.\n\nFix forces the cloned adhoc record\u0027s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server\u0027s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user\u0027s shared server persists a row owned by the caller, not shared, and without the source\u0027s stored credentials.\n\nThis issue affects pgAdmin 4: from 9.0 before 9.17.",
  "id": "GHSA-p547-rjmg-jqr4",
  "modified": "2026-07-31T18:32:17Z",
  "published": "2026-07-31T18:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17349"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgadmin-org/pgadmin4/issues/10200"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/64a9cdbd6a240a962144f84418beaf9e66419779"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/a7e74a6ed685bc34e1f77a8b6a94d00fa3dff815"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

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.

Detection rules are retrieved from Rulezet.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.

Action not permitted

CVE-2026-17349 (GCVE-0-2026-17349)

GHSA-P547-RJMG-JQR4

Tags

Sightings

Nomenclature