ZeroPath at Black Hat USA 2026

pgAdmin 4 CVE-2026-7813: Brief Summary of a Critical Multi Tenant Authorization Bypass in Server Mode

A brief summary of CVE-2026-7813, a CVSS 9.9 authorization vulnerability in pgAdmin 4 server mode that allowed authenticated users to access other users' private servers, leak credentials, and achieve arbitrary command execution via the Shared Servers feature.

CVE Analysis

7 min read

ZeroPath CVE Analysis
ZeroPath CVE Analysis

2026-05-11

pgAdmin 4 CVE-2026-7813: Brief Summary of a Critical Multi Tenant Authorization Bypass in Server Mode
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A systemic authorization failure in pgAdmin 4's server mode allowed any authenticated user to reach across tenant boundaries, accessing other users' private database servers, credentials, and background processes by simply guessing numeric object IDs. Worse, the Shared Servers feature exposed a path to arbitrary command execution: an attacker could write a malicious shell command into another user's connection configuration, which pgAdmin would then execute the next time that user connected to their database.

pgAdmin 4 is the most popular and feature rich open source administration and development platform for PostgreSQL. Given PostgreSQL's extensive adoption across industries, pgAdmin 4 deployments in server (multi tenant) mode are common in enterprise environments, making this vulnerability particularly relevant to database administrators and security teams managing shared infrastructure.

Technical Information

Cross User Data Access via Object ID Guessing

The root cause of CVE-2026-7813 is straightforward: multiple API endpoints in pgAdmin 4 server mode fetched user owned objects without filtering by the requesting user's identity. The affected modules include Server Groups, Servers, Shared Servers, Background Processes, and the Debugger. Because object IDs are sequential integers, an authenticated user could trivially enumerate and retrieve private assets belonging to other users.

The scope of the problem was significant. The development team identified and replaced approximately 20 scattered unfiltered queries and fixed over 155 unguarded callers at the connection manager chokepoint. This was not a single missed authorization check; it was a systemic absence of tenant scoping across the application's data access layer.

Shared Server Privilege Escalation

The Shared Servers feature compounded the authorization failure with several additional attack vectors:

Arbitrary Command Execution via passexec_cmd: The passexec_cmd field stores a shell command that pgAdmin executes when establishing a database connection (it is used to retrieve passwords dynamically). Non owners could write to this field through the API. An attacker could set passexec_cmd to a malicious command on a Shared Server, and when the legitimate owner next connected to that server, the attacker's command would execute in the owner's process context.

Credential Leakage: Owner SSL file paths, passfile data, and passexec_cmd values were exposed in connection parameters during Shared Server creation and property merges. These sensitive database authentication secrets were visible to any user with access to the shared server record.

Owner Data Corruption via SQLAlchemy Session Mutations: Several fields lacked per user persistence entirely. When a non owner edited fields such as kerberos_conn, tags, or post_connection_sql, the changes mutated the owner's record directly through SQLAlchemy session side effects. Additional owner only fields (passexec_cmd, passexec_expiration, db_res, db_res_type) were also writable by non owners through the API without any write guards.

Attack Flow

An attacker exploiting this vulnerability would proceed as follows:

  1. Authenticate to the pgAdmin 4 server mode instance with any valid user account.
  2. Enumerate object IDs across the affected endpoints (Server Groups, Servers, Shared Servers, Background Processes, Debugger) by iterating sequential integer IDs.
  3. Retrieve private server configurations and credentials belonging to other users from the unfiltered API responses.
  4. Optionally, escalate privileges by writing a malicious shell command to the passexec_cmd field of a Shared Server owned by another user.
  5. Wait for the legitimate owner to connect to that server. pgAdmin executes the passexec_cmd value as a shell command, running the attacker's payload in the owner's process context.

The entire attack requires only a valid authenticated session and the ability to make standard API requests. No special privileges or complex exploitation techniques are needed.

Remediation Architecture

The fix, delivered across two pull requests (PR #9830 and PR #9835), introduced structural changes to the authorization model:

A new server_access.py module centralizes access control, replacing the scattered unfiltered queries with guarded functions that enforce strict ownership validation. A UserScopedMixin.for_user() method was applied across 10 user owned models, ensuring that database queries automatically filter by the current user's ID. The connection_manager() now raises an ObjectGone exception and returns HTTP 410 when access is denied in server mode, providing clear audit signals. Five new columns were added to the SharedServer model for per user feature parity, and explicit write guards block non owners from setting owner only fields.

Affected Systems and Versions

This vulnerability affects pgAdmin 4 versions before 9.15 when running in server mode (the multi tenant deployment model). Desktop mode deployments, which are single user by nature, are not affected by the cross user data access aspects of this vulnerability.

The fix is included in pgAdmin 4 version 9.15, released on May 11, 2026.

Vendor Security History

The pgAdmin 4 v9.15 release addressed eight distinct security vulnerabilities (CVE-2026-7813 through CVE-2026-7820) alongside 19 total bug fixes. The security issues spanned multiple categories including cross site scripting, SQL injection, and unsafe deserialization, indicating a broad security audit was conducted.

This is not the first server mode authorization issue in pgAdmin 4. Earlier in 2026, CVE-2026-1707 disclosed a restore restriction bypass via key disclosure affecting versions up to 9.11. The recurrence of authorization issues in the server mode architecture suggests that organizations deploying pgAdmin 4 in multi tenant configurations should treat each release as a priority update and consider additional network level access controls around the pgAdmin instance.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Jira
  • Linear
  • Slack
  • Security Compass
Security magnifying glass visualization