External risk intelligence

pgAdmin 4 Improper Credential Handling Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-17349

pgAdmin is a management tool for PostgreSQL. While it can be internet-facing, it is commonly deployed as an internal administrative interface restricted to trusted networks. Therefore, while it is reachable in some environments, widespread public exposure is not the default or standard deployment pattern for this application.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability has been identified in pgAdmin, a tool used for managing PostgreSQL databases. This issue, when exploited, could allow a user to gain unauthorized access to database credentials stored by another user, potentially granting them unintended database privileges. The primary concern is to confirm if your environment uses this software and is potentially exposed.

Unauthorized access to database credentials.
Confirms exposure when using shared servers.
Verify usage and assess relevant risk.

Attack Path

How an attacker could exploit the issue

An attacker could leverage an existing account to trigger a cloning process for another user's shared server within pgAdmin. This cloning action improperly copies sensitive stored credentials, allowing the attacker to then use these credentials to access databases belonging to the original owner.

Requires an attacker account.
Triggered by cloning another user's server.
Risk of unauthorized database access.

Live Threat

Current exploitation, exposure, and threat context

When a non-administrator user connects to a shared server owned by another user, the system could clone the server entry, inheriting the original owner's credentials and access. This cloned entry, persisted before the connection is even attempted, allows the non-administrator to use the original user's database credentials and associated privileges.

Stored database credentials and user ownership.
Cloning a shared server entry by a non-owner.
Unauthorized access to database resources.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability in pgAdmin's server cloning function requires immediate attention from teams managing database infrastructure and application deployments. The first step is to inventory all instances of pgAdmin 4, determine their exposure, and identify the business criticality of any shared servers. Subsequently, the accountable owner should be located to plan remediation, prioritizing systems with wider access or critical data.

Database administration and platform teams own resolution.
Verify shared server configurations and user access.
Coordinate vendor update deployment during maintenance.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is pgAdmin 4?

pgAdmin 4 is a popular open-source administration and management platform for PostgreSQL databases. Users rely on it to build schemas, write SQL queries, and manage database configurations through a web-based interface. It often handles sensitive connection details, such as passwords and SSH tunnel credentials, allowing team members to connect to shared database environments efficiently.

What does CWE-522 and CWE-639 mean for CVE-2026-17349?

These codes represent Insufficiently Protected Credentials and Authorization Bypass. In simple terms, this vulnerability occurs when the system fails to verify if a user should have access to specific server settings. Because the software improperly clones server configurations, it mistakenly copies credentials from one user to another, effectively allowing a user to bypass access controls and adopt the permissions of the original server owner.

How is this credential vulnerability triggered?

An attacker needs an existing account within the pgAdmin environment to trigger the flaw. By initiating an 'adhoc connect' request using the ID of a shared server owned by someone else, the software automatically creates a clone of that server. Crucially, this behavior is not triggered by standard operations on servers you own; it specifically occurs when the system incorrectly persists a new, unauthorized copy of a foreign server entry that includes the source's sensitive password data.

Is my pgAdmin 4 instance at risk?

According to Halo Surface Signal, risk depends heavily on how your instance is deployed. While pgAdmin is often kept behind internal firewalls as a private administrative tool, any installation accessible from the internet or exposed to untrusted users increases the likelihood of a malicious actor reaching the server-cloning feature. You should care most if your setup allows users to share servers, as this is the primary mechanism for the unauthorized credential inheritance.

How do I secure my environment against this?

First, identify every pgAdmin 4 instance running versions 9.0 through 9.16 within your infrastructure. Since this is a software flaw in the server cloning logic, the only effective way to prevent the unauthorized copying of credentials is to apply the official vendor patch. Work with your platform team to schedule a maintenance window to update your instances, and review your internal user access policies to ensure only trusted individuals have account-level access to the interface.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.