Find a vulnerability

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Materialized Views"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "\ubc30\uc2b9\uc6d0 (Bae Seung-won), Ajou University (@baeseungwon1010) \u003cqotmddnjs@ajou.ac.kr\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4\u0027s materialized view refresh passed the target database\u0027s name to psql\u0027s --dbname argument unchanged. libpq treats a --dbname value containing \"=\" (or a postgresql:// URI) as a full connection string, whose keywords override the host, port and other settings pgAdmin had supplied. A database whose name is such a string, which any role with CREATEDB can create, therefore redirected the psql process pgAdmin starts for the refresh to a host and port of the creator\u0027s choosing, and the connecting user\u0027s saved server password was presented to that endpoint. It also let the pgAdmin host be made to open connections to arbitrary addresses.\n\nThe same weakness was fixed for Backup, Restore, Maintenance and Import/Export Data in earlier releases (CVE-2026-86862); the materialized view refresh was the remaining caller. The fix routes the name through the same database_conninfo() helper, so libpq treats it strictly as a database name.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same threat model and vector as CVE-2026-86862, of which this is the remaining caller. The attacker needs a database role with CREATEDB on a server another pgAdmin user connects to, and that user must refresh a materialized view in that database; no other precondition applies, so Attack Complexity is Low. Confidentiality is High because the victim\u0027s saved server password is sent to the attacker\u0027s endpoint. Integrity and Availability are None. Scope is Unchanged, as for CVE-2026-86862: the credential is captured from the user\u0027s own connection rather than a different authority being exercised."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:N because no condition outside the attacker\u0027s control is needed beyond the victim using the feature. VC:H for the captured password; no subsequent-system impact is claimed from the flaw itself."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-88",
              "description": "CWE-88 Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-918",
              "description": "CWE-918 Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:20.208Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10645"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/a1a43e8c28cf10cec73df0c476905562d19af483"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Materialized view refresh redirects its connection through a crafted database name"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116252",
    "datePublished": "2026-10-30T19:55:20.208Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:20.208Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication",
            "User Management"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/user_management/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Zohaib \u003cofficialzohaib84@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 did not invalidate a user\u0027s existing sessions when their password changed, either through the user\u0027s own change password dialog or through an administrator resetting it in User Management. A session established before the change, for example on another device or by someone who had obtained the old password or a session cookie, therefore stayed logged in after the change, which is the step a user or administrator takes precisely to cut such access off. It remained usable until it expired.\n\nThe fix rotates the user\u0027s session identifier (fs_uniquifier) whenever the password is changed, so every other session of that user is logged out. The session that made the change is logged in again and keeps its database connections. Saved server passwords, including those for shared servers, are re-encrypted under the new key; any that cannot be decrypted are cleared and the user is told. If re-encryption fails, the sessions are still revoked and the saved passwords are cleared rather than the change failing.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.2,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "The attacker must already hold a live session of the victim, obtained separately (a stolen session cookie or a known old password), so Attack Complexity is High and Privileges Required is Low. The flaw gives no capability the attacker did not already have; it only lets that access persist after the victim\u0027s password change until the session expires, so Confidentiality and Integrity are Low and Availability is None. Scope is Unchanged: the access is the victim\u0027s own pgAdmin account."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 2.3,
            "baseSeverity": "LOW",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P because a session must have been obtained beforehand by other means. VC:L/VI:L for continued access to the victim\u0027s account; no subsequent-system impact."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613 Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:19.613Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10646"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/67eab1ba891d24209eb0d4bac050dcc8068d93b7"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: A user\u0027s other sessions survive a change of their password"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116251",
    "datePublished": "2026-10-30T19:55:19.613Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:19.613Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "File Manager",
            "Import/Export Servers",
            "Backup",
            "Restore",
            "Import/Export Data"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/file_manager/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export_servers/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "MUTED CYBERSECURITY S.L. \u003ccybersec@mut3dcybersecurity.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager\u0027s save_file; these were the remaining paths.\n\nExploitation requires creating such a link or FIFO inside the user\u0027s storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race.\n\nThe fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "LOCAL",
            "availabilityImpact": "LOW",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Threat model: an operating-system user other than the pgAdmin service account who can write into a storage directory pgAdmin uses (a shared or network-mounted storage backend), and who also has, or works with, a pgAdmin account using it. An attacker with access to the host as the service account gains nothing from this flaw, so the Attack Vector is Local. Attack Complexity is High: the link must be planted and a race between the check and the open won. Confidentiality and Integrity are High because a file readable or writable by the pgAdmin account can be read (including loaded into a table) or overwritten; Availability is Low for a clobbered file or a hung request. Scope is Unchanged: the operations run with the authority pgAdmin already holds."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.3,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the race and for the write access to the storage backend obtained outside pgAdmin. VC:H/VI:H/VA:L as above; no subsequent-system impact."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-367",
              "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-59",
              "description": "CWE-59 Improper Link Resolution Before File Access (\u0027Link Following\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:18.713Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10647"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116250",
    "datePublished": "2026-10-30T19:55:18.713Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:18.713Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Import/Export Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 resolves a server\u0027s password file, SSL certificate, key, CRL and SSH tunnel identity file relative to the user\u0027s storage directory, but get_complete_file_path() only stripped leading slashes before joining the two. A path such as \"../\u003canother user\u003e/.pgpass\", set through the server dialog, the REST API or a servers.json import, therefore named another user\u0027s file, and connecting used that user\u0027s saved passwords, client certificate or SSH key. The sslkeylogfile connection parameter was passed to libpq unchanged, so a path outside storage let libpq create or append a file as the account running pgAdmin.\n\nmake_conninfo() also quoted connection parameter values but not their names, so a crafted parameter name could smuggle additional keyword=value pairs past these checks.\n\nThe fix requires the resolved path, with symbolic links followed, to stay inside the user\u0027s storage directory or the named shared storage directory, confines sslkeylogfile the same way, and accepts only exact libpq keywords as connection parameter names. A refused path or keyword is reported instead of letting libpq fall back to a default.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the victim must keep such a file in their storage directory, and the attacker must know its name and a host and role it is accepted for. Scope is Changed because the connection is made to a database server with another user\u0027s credentials, an authority the attacker was never given; Confidentiality and Integrity are High for that access. Availability is Low for the file sslkeylogfile can create or append to outside storage."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the victim\u0027s file and its name, which the attacker does not control. VC:H for the credential read through pgAdmin, VI:L/VA:L for the sslkeylogfile write; SC:H/SI:H for the database server reached with the other user\u0027s identity."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73 External Control of File Name or Path",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:18.121Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10650"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/2afe505ef4a31591796449d54ab1604355ff06c2"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Connection file paths and parameter keys escape the user\u0027s storage directory"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116249",
    "datePublished": "2026-10-30T19:55:18.121Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:18.121Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Import/Export Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In pgAdmin 4 server mode only administrators are meant to share a server with all users; the server dialog shows the Shared switch only to them. The create and update endpoints of the server API, however, stored the \"shared\" flag and shared username they were sent, so any user able to register a server could share one with every other user. The servers.json import had a similar gap: a non-administrator\u0027s \"Shared\" entries were removed only after validation, so a file that also held an invalid entry could create a shared server.\n\nA shared server carries no credentials, so this gives no direct access. It lets a user plant a server, named to look trusted, in every other user\u0027s tree and pointing at a host the user controls; anyone who then connects to it presents their own database password to that host.\n\nThe fix refuses a non-administrator\u0027s request that would share a server with HTTP 403, prunes a non-administrator\u0027s shared entries from a servers.json import before validating it, and warns at startup about servers shared earlier by non-administrators.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. User Interaction is Required: another user must connect to the planted server. Scope is Changed because what is captured is the other user\u0027s credential for their own database servers; Confidentiality is High for that credential. Integrity is None (the planted entry only alters what other users see) and Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 6,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:L/VA:N/SC:H/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. UI:A because the victim must actively connect. VI:L for the planted entry in other users\u0027 trees, SC:H for the other user\u0027s database credentials captured for use elsewhere."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:17.531Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10651"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/d761942d0bb84d52b18e81307064dd08e26224e3"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Non-administrators can share a server with every user"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116248",
    "datePublished": "2026-10-30T19:55:17.531Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:17.531Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account\u0027s saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account\u0027s private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities.\n\nThe fix gives each of these parameters a value in server mode, the user\u0027s own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the service account must have a password file entry or client certificate that a server the attacker can reach accepts, a deployment condition the attacker does not control. Scope is Changed because the connection is made with the service account\u0027s database credentials, an identity the attacker was never granted; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the service account\u0027s credential and an accepting server. VC:H because the service account\u0027s stored secret is used through pgAdmin; SC:H/SI:H for the database server reached with that identity."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:16.935Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10652"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/32db693198f28b78fe2af12a726b80a68eb78cb2"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: libpq uses the pgAdmin service account\u0027s own password file and client certificate"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116247",
    "datePublished": "2026-10-30T19:55:16.935Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:16.935Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "PSQL Tool",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/bgprocess/processes.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/psql/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "To pass a server\u0027s password to psql and to the utilities pgAdmin 4 runs as background processes, the server manager wrote it into pgAdmin\u0027s own process environment: as PGPASSWORD for the PSQL tool, and under a per-process variable for a utility. Nothing removed it afterwards. pgAdmin\u0027s environment is shared by every user\u0027s requests and copied into every process it starts, so in server mode another user\u0027s later PSQL session or utility inherited the password, and libpq used PGPASSWORD for any connection made without a password of its own, letting one user connect with another user\u0027s saved password.\n\nThe fix puts the password only into the environment built for the process that needs it and starts psql with a copy of pgAdmin\u0027s environment instead of the environment itself.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Requires the PSQL tool to be enabled (ENABLE_PSQL) and another user to have used it (User Interaction Required), and the attacker\u0027s connection or utility to follow in the same pgAdmin process (Attack Complexity High). The gain is real only for users without the PSQL tool permission: a user who has it already holds a shell as the pgAdmin account. Scope is Changed because the password belongs to another user; Confidentiality is High for it. Integrity is Low, reflecting that the attacker\u0027s use of the other user\u0027s database identity is constrained by these conditions; Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:L/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the timing and configuration conditions, UI:P because the victim only has to use the PSQL tool. VC:H for the leaked password; SC:H/SI:L for the database server it opens."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-214",
              "description": "CWE-214 Invocation of Process Using Visible Sensitive Information",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-526",
              "description": "CWE-526 Cleartext Storage of Sensitive Information in an Environment Variable",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:16.276Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10653"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/0eefa38f774dce07c1f939d87f2993b36e2313b9"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Server passwords are left in pgAdmin\u0027s process environment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116246",
    "datePublished": "2026-10-30T19:55:16.276Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:16.276Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "libpq looks a connection service up in the service file of the operating-system account running pgAdmin 4, and an entry there can hold a password or name a password file or client certificate. In server mode any user could set a server\u0027s Service, or a \"service\" connection parameter, to one of those entries and connect with its credentials. A PGPASSWORD or PGSERVICE variable set for that account was likewise used by libpq for every connection without a value of its own and passed on to the utilities, and pg_dumpall read a maintenance database name such as \"service=...\" as a connection string.\n\nThe fix adds the SERVER_MODE_ALLOWED_SERVICES setting, empty by default: in server mode only a listed service can be used, the servicefile parameter is refused, and PGPASSWORD and PGSERVICE are removed from pgAdmin\u0027s environment at startup. The allowlist is checked again on the final connection string, and the pg_dumpall database name is wrapped as a connection string.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server or set connection parameters. Attack Complexity is High: the service account\u0027s service file (or environment) must hold a credential-bearing entry that a reachable server accepts, a deployment condition the attacker does not control. Scope is Changed because the connection uses credentials configured for the service account, never granted to the attacker; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the credential-bearing service entry. VC:H because the stored secret is used through pgAdmin; SC:H/SI:H for the database server reached with it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:15.679Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10654"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/a0c8f4857f732c6f5e5bacf4b289b811bb5c6a06"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Connection services are not restricted in server mode"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116245",
    "datePublished": "2026-10-30T19:55:15.679Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:15.679Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Authentication",
            "PSQL Tool",
            "Backup",
            "Restore"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/locker.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "When a pgAdmin 4 connection was not meant to use a Kerberos user\u0027s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account\u0027s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account\u0027s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account\u0027s logon in the same way. psql was also started with pgAdmin\u0027s environment, which could hold another user\u0027s credential cache while that user was connecting.\n\nThe fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the service account must hold a credential cache or keytab, or run on a domain-joined Windows host, and a reachable server must accept that principal. Scope is Changed because the connection is made as the service account\u0027s principal, an identity the attacker was never granted; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the Kerberos deployment conditions. VC:H because the service account\u0027s credential is used through pgAdmin; SC:H/SI:H for the database server reached with it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:15.101Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10655"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: libpq uses the pgAdmin service account\u0027s Kerberos credentials"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116244",
    "datePublished": "2026-10-30T19:55:15.101Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:15.101Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Preferences",
            "Backup",
            "Restore",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Harsh Singh \u003c93harshsingh@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 runs pg_dump, pg_restore, pg_dumpall and psql from the binary path a user sets in their preferences. In server mode the binary path was refused only when it lay under the per-user storage directory (STORAGE_DIR), not under a SHARED_STORAGE directory, which ordinary users can upload files to. A user could therefore upload an executable to shared storage, point their binary path at it, and have pgAdmin run it as the operating-system account running pgAdmin. On POSIX, files created through pgAdmin are not executable, so this is exploitable where any file with an executable name can run, such as Windows server mode.\n\nThe fix checks the binary path against every SHARED_STORAGE directory as well, after expanding $DIR, collapsing \"..\" and resolving symbolic links, compares directories in a way a different spelling on a case-insensitive filesystem cannot bypass, refuses a path containing a NUL, and enforces the check wherever binary paths are resolved, including for the PSQL tool.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can upload to a shared storage directory and set their binary path. Attack Complexity is High: SHARED_STORAGE must be configured and writable by the user, and the platform must let an uploaded file run (Windows server mode; on POSIX uploads are not executable). Confidentiality, Integrity and Availability are High for code execution as the pgAdmin service account. Scope is Unchanged, following CVE-2026-17347: the code runs with the authority pgAdmin already holds."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the deployment and platform conditions. VC:H/VI:H/VA:H for code execution as the pgAdmin account; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-426",
              "description": "CWE-426 Untrusted Search Path",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-427",
              "description": "CWE-427 Uncontrolled Search Path Element",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:14.513Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10656"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/9e95d9a72155beb40d3735cadf6ae754f627cac7"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Utility binary path can point at a shared storage directory"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116243",
    "datePublished": "2026-10-30T19:55:14.513Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:14.513Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account\u0027s ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account\u0027s key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account.\n\nThe fix makes tunnels in server mode use only the identity file or password the user configured: the service account\u0027s keys, configuration and agent are no longer used, and an identity file that cannot be found in the user\u0027s storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server with an SSH tunnel. Attack Complexity is High: the service account must have an unencrypted default key, agent or configuration that a host the attacker can name accepts. Scope is Changed because the tunnel authenticates as the service account to another system, an identity the attacker was never granted; Confidentiality and Integrity are High for the access it gives. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the service account\u0027s SSH identity and an accepting host. VC:H because the service account\u0027s key is used through pgAdmin; SC:H/SI:H for the SSH host and the network reached through it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:13.843Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10662"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/d52fe4740eb1af89d940f2e412bd66a0a89f08bb"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: SSH tunnels use the pgAdmin service account\u0027s own SSH identity"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116242",
    "datePublished": "2026-10-30T19:55:13.843Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:13.843Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Import/Export Data"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Yonghwa Lee (Xint by Theori) \u003cunderdog@theori.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4\u0027s Import/Export Data tool wraps a user\u0027s query export in a psql \\copy (...) TO command and checks that the query\u0027s parentheses are balanced so that nothing can escape the wrapper. The check rejected a backslash inside a single-quoted string, but not inside a double-quoted identifier, where it treated the next double quote as closing the identifier. psql\u0027s \\copy parser applies the connection\u0027s escape character to whichever quote opened a token, so with standard_conforming_strings off a backslash-escaped double quote does not close the identifier. pgAdmin\u0027s and psql\u0027s view of the quoting then diverged, a closing parenthesis hidden from the check ended the \\copy (...) wrapper, and a following TO PROGRAM clause was executed by psql on the pgAdmin host, as the operating-system account running pgAdmin, before the server rejected the statement. An ordinary database role can turn standard_conforming_strings off for itself, and the Import/Export Data permission is granted to non-administrators by default.\n\nThis is a bypass of the fix for CVE-2026-17566. The fix rejects any backslash inside a double-quoted identifier, as was already done for single-quoted strings, since its meaning depends on a server setting that cannot be known reliably when the query is validated.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.9,
            "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:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same threat model and outcome as CVE-2026-17566, of which this is a bypass: any authenticated user with the Import/Export Data permission (granted by default) and an ordinary database role, which can set standard_conforming_strings itself, so Attack Complexity is Low. Confidentiality, Integrity and Availability are High for command execution on the pgAdmin host. Scope is Changed, as for CVE-2026-17566, because the command runs on the pgAdmin host rather than within the database server the user is connected to."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 9.4,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry and the same vector as CVE-2026-17566. AT:N because no condition outside the attacker\u0027s control is needed. VC/VI/VA:H for the pgAdmin host and SC/SI/SA:H for the systems reachable from it with its credentials."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78 Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-115",
              "description": "CWE-115 Misinterpretation of Input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:13.194Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10663"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/9be31a019f780647fb689c458408c8803263c812"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Import/Export Data query export runs a command through a backslash in a double-quoted identifier"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116241",
    "datePublished": "2026-10-30T19:55:13.194Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:13.194Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "File Manager",
            "Import/Export Data",
            "Backup",
            "Restore",
            "Query Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/file_manager/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 validates a path into the user\u0027s storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:\n\n- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.\n- Listing a folder decoded the path a second time after the check, so a folder named like an encoded \"..\", which a user can create, listed any directory on the host.\n- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user\u0027s storage directory name is a prefix of another\u0027s, another user\u0027s files could be read, deleted or moved; download also checked the path appended to itself.\n- Creating a folder could create one in another user\u0027s directory.\n\nThe fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Scored for the worst variant, which needs only an authenticated user in server mode: reading any file the pgAdmin account can read through the Query Tool\u0027s file open, and listing any directory. Attack Complexity is Low. Confidentiality is High because that includes pgAdmin\u0027s own configuration and database. Integrity is None for this variant; the read, delete and rename of another user\u0027s files need a deployment where one user\u0027s storage directory name is a prefix of another\u0027s, and the write outside storage is limited to Windows server mode. Scope is Unchanged: the access is with the authority of the pgAdmin account."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:N for the any-file read, which needs no deployment condition. VC:H; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-367",
              "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:12.603Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10674"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/ad6c028cff625a095676065767c7b80219205d28"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: File Manager and storage-path tools act on a different path from the one checked"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116240",
    "datePublished": "2026-10-30T19:55:12.603Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:12.603Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/ldap.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/internal.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Yves Soete of Blacksight LLC \u003cyves.soete@blacksight.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 keeps an account per authentication source, so the same username can exist as, for example, an internal account and an LDAP account. After LDAP or Kerberos authenticated a user, pgAdmin chose the account to log in by username alone, or took the account Flask-Security\u0027s login form had looked up, without checking that it came from the source that authenticated the user. The session therefore belonged to another account, with its role, its servers and its saved database passwords:\n\n- An LDAP or Kerberos user whose username matched an internal account was logged in as that internal account, including the administrator account created when pgAdmin is first set up.\n- With internal authentication listed before LDAP or Kerberos in AUTHENTICATION_SOURCES, the login form\u0027s internal validation looks up the account whose email was typed and keeps it even though its password does not match. A Kerberos user could type another Kerberos user\u0027s principal and be logged in as that user, and an LDAP user could do the same with an LDAP account whose email is their username.\n\nExploitation requires valid credentials for an LDAP directory or Kerberos realm that pgAdmin is configured to use.\n\nThe fix looks the account up by the authenticated username and the source that authenticated it, and no longer uses the account the login form found for any source but internal authentication. Internal authentication logs in that account only if it is an internal account. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "The attacker needs valid credentials in the configured LDAP directory or Kerberos realm, so Privileges Required is Low. Attack Complexity is High: the attacker\u0027s directory username must match the target account\u0027s username, which a directory user does not normally choose, or, for the typed-principal variant, internal authentication must be listed before Kerberos. The session is the target account\u0027s, possibly the initial administrator\u0027s, so Confidentiality, Integrity and Availability of pgAdmin are High (an administrator can create, change and delete users). Scope is Changed because the session uses the target account\u0027s saved database passwords, connecting to PostgreSQL servers as a role the attacker was never given."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 8.9,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the username collision or the order of AUTHENTICATION_SOURCES. VC:H/VI:H/VA:H for the target pgAdmin account; SC:H/SI:H for the PostgreSQL servers reached with its saved credentials."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-639",
              "description": "CWE-639 Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:12.002Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10675"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/7378060e5c8f7c3279b8138d371e13fd8b45a729"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/269e32d5ee01f2eb5de36e464d44487a831f2424"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: An LDAP or Kerberos login is logged in to another account with the same username"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116239",
    "datePublished": "2026-10-30T19:55:12.002Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:12.002Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication",
            "Password Recovery",
            "User Management"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/about/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 locks an internal account after MAX_LOGIN_ATTEMPTS failed logins (3 by default). The limit could be bypassed, giving an unauthenticated attacker an unlimited number of password guesses against any internal account, including the administrator\u0027s, in the default configuration:\n\n- Flask-Security registers its own views next to pgAdmin\u0027s. A login submitted to its /login view was checked and logged in without pgAdmin\u0027s failed login count or lock. Its /verify view checked a signed-in user\u0027s password without limit, its /change view changed a password without pgAdmin\u0027s change password permission or re-encrypting the user\u0027s saved server passwords, and its /reset views sent and applied password resets for accounts that are not internal or are locked.\n- The internal account was looked up by its exact username, while the login form matches the email ignoring case, so a login with the username typed in another case was neither counted nor checked for the lock.\n- With LDAP or webserver authentication also configured, a wrong internal password was never counted, and with Kerberos or webserver authentication configured a guess could be answered without being counted.\n\nIn addition, where accounts from different authentication sources share an email address, a password reset could be sent for, or applied to, an account from another source, and the About box showed the server configuration to a user whose email was that of an administrator\u0027s account.\n\nThe fix refuses submissions to Flask-Security\u0027s own views, counts every failed internal login however the username is typed and whatever other sources are configured, no longer lets a login that posts a password fall back to an authentication source that does not check it, and locks only internal authentication. Password resets and the About box act only on the user\u0027s own internal account. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Scored for the worst variant, which needs no account and no special configuration: unlimited password guesses against an internal account, including the administrator\u0027s, through Flask-Security\u0027s own login view or a username typed in another case. Attack Complexity is High because success still depends on guessing the account\u0027s password. A guessed account gives that account\u0027s access to pgAdmin, so Confidentiality, Integrity and Availability are High (an administrator can create, change and delete users). Scope is Unchanged: the flaw removes the limit on guesses; any impact beyond pgAdmin follows only from a password the attacker has guessed."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 9.2,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AC:H and AT:P because success depends on guessing a password. VC:H/VI:H/VA:H for the guessed pgAdmin account; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-307",
              "description": "CWE-307 Improper Restriction of Excessive Authentication Attempts",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-863",
              "description": "CWE-863 Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:11.056Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10676"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/58c531d831179dc9b0a5bf873ccb80c71c8d387a"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/35c9235d17a7d5a99778f01b2f1b9e5e3a3b7fde"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/c6ef41a951012cd877a1992b5dac681eec36e48d"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: The failed login limit can be bypassed, and Flask-Security\u0027s own views skip pgAdmin\u0027s login and password checks"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116238",
    "datePublished": "2026-10-30T19:55:11.056Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:11.056Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Materialized Views"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/views/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "\ubc30\uc2b9\uc6d0 (Bae Seung-won), Ajou University (@baeseungwon1010) \u003cqotmddnjs@ajou.ac.kr\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4\u0027s materialized view refresh passed the target database\u0027s name to psql\u0027s --dbname argument unchanged. libpq treats a --dbname value containing \"=\" (or a postgresql:// URI) as a full connection string, whose keywords override the host, port and other settings pgAdmin had supplied. A database whose name is such a string, which any role with CREATEDB can create, therefore redirected the psql process pgAdmin starts for the refresh to a host and port of the creator\u0027s choosing, and the connecting user\u0027s saved server password was presented to that endpoint. It also let the pgAdmin host be made to open connections to arbitrary addresses.\n\nThe same weakness was fixed for Backup, Restore, Maintenance and Import/Export Data in earlier releases (CVE-2026-86862); the materialized view refresh was the remaining caller. The fix routes the name through the same database_conninfo() helper, so libpq treats it strictly as a database name.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same threat model and vector as CVE-2026-86862, of which this is the remaining caller. The attacker needs a database role with CREATEDB on a server another pgAdmin user connects to, and that user must refresh a materialized view in that database; no other precondition applies, so Attack Complexity is Low. Confidentiality is High because the victim\u0027s saved server password is sent to the attacker\u0027s endpoint. Integrity and Availability are None. Scope is Unchanged, as for CVE-2026-86862: the credential is captured from the user\u0027s own connection rather than a different authority being exercised."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:N because no condition outside the attacker\u0027s control is needed beyond the victim using the feature. VC:H for the captured password; no subsequent-system impact is claimed from the flaw itself."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-88",
              "description": "CWE-88 Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-918",
              "description": "CWE-918 Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:20.208Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10645"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/a1a43e8c28cf10cec73df0c476905562d19af483"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Materialized view refresh redirects its connection through a crafted database name"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116252",
    "datePublished": "2026-10-30T19:55:20.208Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:20.208Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication",
            "User Management"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/user_management/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Zohaib \u003cofficialzohaib84@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 did not invalidate a user\u0027s existing sessions when their password changed, either through the user\u0027s own change password dialog or through an administrator resetting it in User Management. A session established before the change, for example on another device or by someone who had obtained the old password or a session cookie, therefore stayed logged in after the change, which is the step a user or administrator takes precisely to cut such access off. It remained usable until it expired.\n\nThe fix rotates the user\u0027s session identifier (fs_uniquifier) whenever the password is changed, so every other session of that user is logged out. The session that made the change is logged in again and keeps its database connections. Saved server passwords, including those for shared servers, are re-encrypted under the new key; any that cannot be decrypted are cleared and the user is told. If re-encryption fails, the sessions are still revoked and the saved passwords are cleared rather than the change failing.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4.2,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "The attacker must already hold a live session of the victim, obtained separately (a stolen session cookie or a known old password), so Attack Complexity is High and Privileges Required is Low. The flaw gives no capability the attacker did not already have; it only lets that access persist after the victim\u0027s password change until the session expires, so Confidentiality and Integrity are Low and Availability is None. Scope is Unchanged: the access is the victim\u0027s own pgAdmin account."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 2.3,
            "baseSeverity": "LOW",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P because a session must have been obtained beforehand by other means. VC:L/VI:L for continued access to the victim\u0027s account; no subsequent-system impact."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613 Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:19.613Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10646"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/67eab1ba891d24209eb0d4bac050dcc8068d93b7"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: A user\u0027s other sessions survive a change of their password"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116251",
    "datePublished": "2026-10-30T19:55:19.613Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:19.613Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "File Manager",
            "Import/Export Servers",
            "Backup",
            "Restore",
            "Import/Export Data"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/file_manager/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export_servers/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "MUTED CYBERSECURITY S.L. \u003ccybersec@mut3dcybersecurity.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager\u0027s save_file; these were the remaining paths.\n\nExploitation requires creating such a link or FIFO inside the user\u0027s storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race.\n\nThe fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "LOCAL",
            "availabilityImpact": "LOW",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Threat model: an operating-system user other than the pgAdmin service account who can write into a storage directory pgAdmin uses (a shared or network-mounted storage backend), and who also has, or works with, a pgAdmin account using it. An attacker with access to the host as the service account gains nothing from this flaw, so the Attack Vector is Local. Attack Complexity is High: the link must be planted and a race between the check and the open won. Confidentiality and Integrity are High because a file readable or writable by the pgAdmin account can be read (including loaded into a table) or overwritten; Availability is Low for a clobbered file or a hung request. Scope is Unchanged: the operations run with the authority pgAdmin already holds."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.3,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the race and for the write access to the storage backend obtained outside pgAdmin. VC:H/VI:H/VA:L as above; no subsequent-system impact."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-367",
              "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-59",
              "description": "CWE-59 Improper Link Resolution Before File Access (\u0027Link Following\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:18.713Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10647"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116250",
    "datePublished": "2026-10-30T19:55:18.713Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:18.713Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Import/Export Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 resolves a server\u0027s password file, SSL certificate, key, CRL and SSH tunnel identity file relative to the user\u0027s storage directory, but get_complete_file_path() only stripped leading slashes before joining the two. A path such as \"../\u003canother user\u003e/.pgpass\", set through the server dialog, the REST API or a servers.json import, therefore named another user\u0027s file, and connecting used that user\u0027s saved passwords, client certificate or SSH key. The sslkeylogfile connection parameter was passed to libpq unchanged, so a path outside storage let libpq create or append a file as the account running pgAdmin.\n\nmake_conninfo() also quoted connection parameter values but not their names, so a crafted parameter name could smuggle additional keyword=value pairs past these checks.\n\nThe fix requires the resolved path, with symbolic links followed, to stay inside the user\u0027s storage directory or the named shared storage directory, confines sslkeylogfile the same way, and accepts only exact libpq keywords as connection parameter names. A refused path or keyword is reported instead of letting libpq fall back to a default.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 8.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the victim must keep such a file in their storage directory, and the attacker must know its name and a host and role it is accepted for. Scope is Changed because the connection is made to a database server with another user\u0027s credentials, an authority the attacker was never given; Confidentiality and Integrity are High for that access. Availability is Low for the file sslkeylogfile can create or append to outside storage."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.2,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the victim\u0027s file and its name, which the attacker does not control. VC:H for the credential read through pgAdmin, VI:L/VA:L for the sslkeylogfile write; SC:H/SI:H for the database server reached with the other user\u0027s identity."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73 External Control of File Name or Path",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:18.121Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10650"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/2afe505ef4a31591796449d54ab1604355ff06c2"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Connection file paths and parameter keys escape the user\u0027s storage directory"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116249",
    "datePublished": "2026-10-30T19:55:18.121Z",
    "dateReserved": "2026-10-25T16:26:16.420Z",
    "dateUpdated": "2026-10-30T19:55:18.121Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Import/Export Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In pgAdmin 4 server mode only administrators are meant to share a server with all users; the server dialog shows the Shared switch only to them. The create and update endpoints of the server API, however, stored the \"shared\" flag and shared username they were sent, so any user able to register a server could share one with every other user. The servers.json import had a similar gap: a non-administrator\u0027s \"Shared\" entries were removed only after validation, so a file that also held an invalid entry could create a shared server.\n\nA shared server carries no credentials, so this gives no direct access. It lets a user plant a server, named to look trusted, in every other user\u0027s tree and pointing at a host the user controls; anyone who then connects to it presents their own database password to that host.\n\nThe fix refuses a non-administrator\u0027s request that would share a server with HTTP 403, prunes a non-administrator\u0027s shared entries from a servers.json import before validating it, and warns at startup about servers shared earlier by non-administrators.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.8,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. User Interaction is Required: another user must connect to the planted server. Scope is Changed because what is captured is the other user\u0027s credential for their own database servers; Confidentiality is High for that credential. Integrity is None (the planted entry only alters what other users see) and Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 6,
            "baseSeverity": "MEDIUM",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:N/VI:L/VA:N/SC:H/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. UI:A because the victim must actively connect. VI:L for the planted entry in other users\u0027 trees, SC:H for the other user\u0027s database credentials captured for use elsewhere."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:17.531Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10651"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/d761942d0bb84d52b18e81307064dd08e26224e3"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Non-administrators can share a server with every user"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116248",
    "datePublished": "2026-10-30T19:55:17.531Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:17.531Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account\u0027s saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account\u0027s private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities.\n\nThe fix gives each of these parameters a value in server mode, the user\u0027s own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the service account must have a password file entry or client certificate that a server the attacker can reach accepts, a deployment condition the attacker does not control. Scope is Changed because the connection is made with the service account\u0027s database credentials, an identity the attacker was never granted; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the service account\u0027s credential and an accepting server. VC:H because the service account\u0027s stored secret is used through pgAdmin; SC:H/SI:H for the database server reached with that identity."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:16.935Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10652"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/32db693198f28b78fe2af12a726b80a68eb78cb2"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: libpq uses the pgAdmin service account\u0027s own password file and client certificate"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116247",
    "datePublished": "2026-10-30T19:55:16.935Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:16.935Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "PSQL Tool",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/bgprocess/processes.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/psql/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "To pass a server\u0027s password to psql and to the utilities pgAdmin 4 runs as background processes, the server manager wrote it into pgAdmin\u0027s own process environment: as PGPASSWORD for the PSQL tool, and under a per-process variable for a utility. Nothing removed it afterwards. pgAdmin\u0027s environment is shared by every user\u0027s requests and copied into every process it starts, so in server mode another user\u0027s later PSQL session or utility inherited the password, and libpq used PGPASSWORD for any connection made without a password of its own, letting one user connect with another user\u0027s saved password.\n\nThe fix puts the password only into the environment built for the process that needs it and starts psql with a copy of pgAdmin\u0027s environment instead of the environment itself.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "LOW",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Requires the PSQL tool to be enabled (ENABLE_PSQL) and another user to have used it (User Interaction Required), and the attacker\u0027s connection or utility to follow in the same pgAdmin process (Attack Complexity High). The gain is real only for users without the PSQL tool permission: a user who has it already holds a shell as the pgAdmin account. Scope is Changed because the password belongs to another user; Confidentiality is High for it. Integrity is Low, reflecting that the attacker\u0027s use of the other user\u0027s database identity is constrained by these conditions; Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:L/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the timing and configuration conditions, UI:P because the victim only has to use the PSQL tool. VC:H for the leaked password; SC:H/SI:L for the database server it opens."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-214",
              "description": "CWE-214 Invocation of Process Using Visible Sensitive Information",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-526",
              "description": "CWE-526 Cleartext Storage of Sensitive Information in an Environment Variable",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:16.276Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10653"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/0eefa38f774dce07c1f939d87f2993b36e2313b9"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Server passwords are left in pgAdmin\u0027s process environment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116246",
    "datePublished": "2026-10-30T19:55:16.276Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:16.276Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Backup",
            "Restore",
            "Import/Export Data",
            "Maintenance",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "libpq looks a connection service up in the service file of the operating-system account running pgAdmin 4, and an entry there can hold a password or name a password file or client certificate. In server mode any user could set a server\u0027s Service, or a \"service\" connection parameter, to one of those entries and connect with its credentials. A PGPASSWORD or PGSERVICE variable set for that account was likewise used by libpq for every connection without a value of its own and passed on to the utilities, and pg_dumpall read a maintenance database name such as \"service=...\" as a connection string.\n\nThe fix adds the SERVER_MODE_ALLOWED_SERVICES setting, empty by default: in server mode only a listed service can be used, the servicefile parameter is refused, and PGPASSWORD and PGSERVICE are removed from pgAdmin\u0027s environment at startup. The allowlist is checked again on the final connection string, and the pg_dumpall database name is wrapped as a connection string.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server or set connection parameters. Attack Complexity is High: the service account\u0027s service file (or environment) must hold a credential-bearing entry that a reachable server accepts, a deployment condition the attacker does not control. Scope is Changed because the connection uses credentials configured for the service account, never granted to the attacker; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the credential-bearing service entry. VC:H because the stored secret is used through pgAdmin; SC:H/SI:H for the database server reached with it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862 Missing Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:15.679Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10654"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/a0c8f4857f732c6f5e5bacf4b289b811bb5c6a06"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: Connection services are not restricted in server mode"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116245",
    "datePublished": "2026-10-30T19:55:15.679Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:15.679Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers",
            "Authentication",
            "PSQL Tool",
            "Backup",
            "Restore"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/locker.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "When a pgAdmin 4 connection was not meant to use a Kerberos user\u0027s delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account\u0027s ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account\u0027s Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account\u0027s logon in the same way. psql was also started with pgAdmin\u0027s environment, which could hold another user\u0027s credential cache while that user was connecting.\n\nThe fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server. Attack Complexity is High: the service account must hold a credential cache or keytab, or run on a domain-joined Windows host, and a reachable server must accept that principal. Scope is Changed because the connection is made as the service account\u0027s principal, an identity the attacker was never granted; Confidentiality and Integrity are High on that database server. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the Kerberos deployment conditions. VC:H because the service account\u0027s credential is used through pgAdmin; SC:H/SI:H for the database server reached with it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:15.101Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10655"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: libpq uses the pgAdmin service account\u0027s Kerberos credentials"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116244",
    "datePublished": "2026-10-30T19:55:15.101Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:15.101Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Preferences",
            "Backup",
            "Restore",
            "PSQL Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Harsh Singh \u003c93harshsingh@gmail.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 runs pg_dump, pg_restore, pg_dumpall and psql from the binary path a user sets in their preferences. In server mode the binary path was refused only when it lay under the per-user storage directory (STORAGE_DIR), not under a SHARED_STORAGE directory, which ordinary users can upload files to. A user could therefore upload an executable to shared storage, point their binary path at it, and have pgAdmin run it as the operating-system account running pgAdmin. On POSIX, files created through pgAdmin are not executable, so this is exploitable where any file with an executable name can run, such as Windows server mode.\n\nThe fix checks the binary path against every SHARED_STORAGE directory as well, after expanding $DIR, collapsing \"..\" and resolving symbolic links, compares directories in a way a different spelling on a case-insensitive filesystem cannot bypass, refuses a path containing a NUL, and enforces the check wherever binary paths are resolved, including for the PSQL tool.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can upload to a shared storage directory and set their binary path. Attack Complexity is High: SHARED_STORAGE must be configured and writable by the user, and the platform must let an uploaded file run (Windows server mode; on POSIX uploads are not executable). Confidentiality, Integrity and Availability are High for code execution as the pgAdmin service account. Scope is Unchanged, following CVE-2026-17347: the code runs with the authority pgAdmin already holds."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the deployment and platform conditions. VC:H/VI:H/VA:H for code execution as the pgAdmin account; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-426",
              "description": "CWE-426 Untrusted Search Path",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-427",
              "description": "CWE-427 Uncontrolled Search Path Element",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:14.513Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10656"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/9e95d9a72155beb40d3735cadf6ae754f627cac7"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Utility binary path can point at a shared storage directory"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116243",
    "datePublished": "2026-10-30T19:55:14.513Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:14.513Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Servers"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/server_manager.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4 opens SSH tunnels with the sshtunnel library but gave it neither host_pkey_directories nor ssh_config_file, so it always loaded the unencrypted private keys in ~/.ssh of the operating-system account running pgAdmin, read that account\u0027s ~/.ssh/config (IdentityFile, User, HostName, ProxyCommand) for the tunnel host, and could use its ssh-agent. In server mode any user could therefore configure a tunnel to a host that accepts the service account\u0027s key, with no credentials of their own or with an identity file that did not exist in their storage, and reach it as that account.\n\nThe fix makes tunnels in server mode use only the identity file or password the user configured: the service account\u0027s keys, configuration and agent are no longer used, and an identity file that cannot be found in the user\u0027s storage is reported instead of falling back to ~/.ssh. Desktop mode is unchanged.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Any authenticated user who can register a server with an SSH tunnel. Attack Complexity is High: the service account must have an unencrypted default key, agent or configuration that a host the attacker can name accepts. Scope is Changed because the tunnel authenticates as the service account to another system, an identity the attacker was never granted; Confidentiality and Integrity are High for the access it gives. Availability is None."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/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. AT:P for the service account\u0027s SSH identity and an accepting host. VC:H because the service account\u0027s key is used through pgAdmin; SC:H/SI:H for the SSH host and the network reached through it."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522 Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188 Initialization of a Resource with an Insecure Default",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:13.843Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10662"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/d52fe4740eb1af89d940f2e412bd66a0a89f08bb"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: SSH tunnels use the pgAdmin service account\u0027s own SSH identity"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116242",
    "datePublished": "2026-10-30T19:55:13.843Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:13.843Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Import/Export Data"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Yonghwa Lee (Xint by Theori) \u003cunderdog@theori.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "pgAdmin 4\u0027s Import/Export Data tool wraps a user\u0027s query export in a psql \\copy (...) TO command and checks that the query\u0027s parentheses are balanced so that nothing can escape the wrapper. The check rejected a backslash inside a single-quoted string, but not inside a double-quoted identifier, where it treated the next double quote as closing the identifier. psql\u0027s \\copy parser applies the connection\u0027s escape character to whichever quote opened a token, so with standard_conforming_strings off a backslash-escaped double quote does not close the identifier. pgAdmin\u0027s and psql\u0027s view of the quoting then diverged, a closing parenthesis hidden from the check ended the \\copy (...) wrapper, and a following TO PROGRAM clause was executed by psql on the pgAdmin host, as the operating-system account running pgAdmin, before the server rejected the statement. An ordinary database role can turn standard_conforming_strings off for itself, and the Import/Export Data permission is granted to non-administrators by default.\n\nThis is a bypass of the fix for CVE-2026-17566. The fix rejects any backslash inside a double-quoted identifier, as was already done for single-quoted strings, since its meaning depends on a server setting that cannot be known reliably when the query is validated.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.9,
            "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:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same threat model and outcome as CVE-2026-17566, of which this is a bypass: any authenticated user with the Import/Export Data permission (granted by default) and an ordinary database role, which can set standard_conforming_strings itself, so Attack Complexity is Low. Confidentiality, Integrity and Availability are High for command execution on the pgAdmin host. Scope is Changed, as for CVE-2026-17566, because the command runs on the pgAdmin host rather than within the database server the user is connected to."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 9.4,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry and the same vector as CVE-2026-17566. AT:N because no condition outside the attacker\u0027s control is needed. VC/VI/VA:H for the pgAdmin host and SC/SI/SA:H for the systems reachable from it with its credentials."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-78",
              "description": "CWE-78 Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-115",
              "description": "CWE-115 Misinterpretation of Input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:13.194Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10663"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/9be31a019f780647fb689c458408c8803263c812"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: Import/Export Data query export runs a command through a backslash in a double-quoted identifier"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116241",
    "datePublished": "2026-10-30T19:55:13.194Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:13.194Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "File Manager",
            "Import/Export Data",
            "Backup",
            "Restore",
            "Query Tool"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/file_manager/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 validates a path into the user\u0027s storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:\n\n- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.\n- Listing a folder decoded the path a second time after the check, so a folder named like an encoded \"..\", which a user can create, listed any directory on the host.\n- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user\u0027s storage directory name is a prefix of another\u0027s, another user\u0027s files could be read, deleted or moved; download also checked the path appended to itself.\n- Creating a folder could create one in another user\u0027s directory.\n\nThe fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Scored for the worst variant, which needs only an authenticated user in server mode: reading any file the pgAdmin account can read through the Query Tool\u0027s file open, and listing any directory. Attack Complexity is Low. Confidentiality is High because that includes pgAdmin\u0027s own configuration and database. Integrity is None for this variant; the read, delete and rename of another user\u0027s files need a deployment where one user\u0027s storage directory name is a prefix of another\u0027s, and the write outside storage is limited to Windows server mode. Scope is Unchanged: the access is with the authority of the pgAdmin account."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:N for the any-file read, which needs no deployment condition. VC:H; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-367",
              "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:12.603Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10674"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/ad6c028cff625a095676065767c7b80219205d28"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: File Manager and storage-path tools act on a different path from the one checked"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116240",
    "datePublished": "2026-10-30T19:55:12.603Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:12.603Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/ldap.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/internal.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Yves Soete of Blacksight LLC \u003cyves.soete@blacksight.io\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Hitesh Jambhale \u003chitesh.jambhale@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Kundan Sable \u003ckundan.sable@enterprisedb.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation reviewer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 keeps an account per authentication source, so the same username can exist as, for example, an internal account and an LDAP account. After LDAP or Kerberos authenticated a user, pgAdmin chose the account to log in by username alone, or took the account Flask-Security\u0027s login form had looked up, without checking that it came from the source that authenticated the user. The session therefore belonged to another account, with its role, its servers and its saved database passwords:\n\n- An LDAP or Kerberos user whose username matched an internal account was logged in as that internal account, including the administrator account created when pgAdmin is first set up.\n- With internal authentication listed before LDAP or Kerberos in AUTHENTICATION_SOURCES, the login form\u0027s internal validation looks up the account whose email was typed and keeps it even though its password does not match. A Kerberos user could type another Kerberos user\u0027s principal and be logged in as that user, and an LDAP user could do the same with an LDAP account whose email is their username.\n\nExploitation requires valid credentials for an LDAP directory or Kerberos realm that pgAdmin is configured to use.\n\nThe fix looks the account up by the authenticated username and the source that authenticated it, and no longer uses the account the login form found for any source but internal authentication. Internal authentication logs in that account only if it is an internal account. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "The attacker needs valid credentials in the configured LDAP directory or Kerberos realm, so Privileges Required is Low. Attack Complexity is High: the attacker\u0027s directory username must match the target account\u0027s username, which a directory user does not normally choose, or, for the typed-principal variant, internal authentication must be listed before Kerberos. The session is the target account\u0027s, possibly the initial administrator\u0027s, so Confidentiality, Integrity and Availability of pgAdmin are High (an administrator can create, change and delete users). Scope is Changed because the session uses the target account\u0027s saved database passwords, connecting to PostgreSQL servers as a role the attacker was never given."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 8.9,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AT:P for the username collision or the order of AUTHENTICATION_SOURCES. VC:H/VI:H/VA:H for the target pgAdmin account; SC:H/SI:H for the PostgreSQL servers reached with its saved credentials."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287 Improper Authentication",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-639",
              "description": "CWE-639 Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:12.002Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10675"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/7378060e5c8f7c3279b8138d371e13fd8b45a729"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/269e32d5ee01f2eb5de36e464d44487a831f2424"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: An LDAP or Kerberos login is logged in to another account with the same username"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116239",
    "datePublished": "2026-10-30T19:55:12.002Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:12.002Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Authentication",
            "Password Recovery",
            "User Management"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/authenticate/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/about/__init__.py"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.19",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "datePublic": "2026-10-29T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "In server mode pgAdmin 4 locks an internal account after MAX_LOGIN_ATTEMPTS failed logins (3 by default). The limit could be bypassed, giving an unauthenticated attacker an unlimited number of password guesses against any internal account, including the administrator\u0027s, in the default configuration:\n\n- Flask-Security registers its own views next to pgAdmin\u0027s. A login submitted to its /login view was checked and logged in without pgAdmin\u0027s failed login count or lock. Its /verify view checked a signed-in user\u0027s password without limit, its /change view changed a password without pgAdmin\u0027s change password permission or re-encrypting the user\u0027s saved server passwords, and its /reset views sent and applied password resets for accounts that are not internal or are locked.\n- The internal account was looked up by its exact username, while the login form matches the email ignoring case, so a login with the username typed in another case was neither counted nor checked for the lock.\n- With LDAP or webserver authentication also configured, a wrong internal password was never counted, and with Kerberos or webserver authentication configured a guess could be answered without being counted.\n\nIn addition, where accounts from different authentication sources share an email address, a password reset could be sent for, or applied to, an account from another source, and the About box showed the server configuration to a user whose email was that of an administrator\u0027s account.\n\nThe fix refuses submissions to Flask-Security\u0027s own views, counts every failed internal login however the username is typed and whatever other sources are configured, no longer lets a login that posts a password fall back to an authentication source that does not check it, and locks only internal authentication. Password resets and the About box act only on the user\u0027s own internal account. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.1,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Scored for the worst variant, which needs no account and no special configuration: unlimited password guesses against an internal account, including the administrator\u0027s, through Flask-Security\u0027s own login view or a username typed in another case. Attack Complexity is High because success still depends on guessing the account\u0027s password. A guessed account gives that account\u0027s access to pgAdmin, so Confidentiality, Integrity and Availability are High (an administrator can create, change and delete users). Scope is Unchanged: the flaw removes the limit on guesses; any impact beyond pgAdmin follows only from a password the attacker has guessed."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 9.2,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry. AC:H and AT:P because success depends on guessing a password. VC:H/VI:H/VA:H for the guessed pgAdmin account; no subsequent-system impact is claimed."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-307",
              "description": "CWE-307 Improper Restriction of Excessive Authentication Attempts",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-863",
              "description": "CWE-863 Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T19:55:11.056Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10676"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/58c531d831179dc9b0a5bf873ccb80c71c8d387a"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/35c9235d17a7d5a99778f01b2f1b9e5e3a3b7fde"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/c6ef41a951012cd877a1992b5dac681eec36e48d"
        }
      ],
      "source": {
        "discovery": "INTERNAL"
      },
      "title": "pgAdmin 4: The failed login limit can be bypassed, and Flask-Security\u0027s own views skip pgAdmin\u0027s login and password checks"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-116238",
    "datePublished": "2026-10-30T19:55:11.056Z",
    "dateReserved": "2026-10-25T16:26:16.419Z",
    "dateUpdated": "2026-10-30T19:55:11.056Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}