CVE-2026-91924 in pgweb
Summary
by MITRE • 09/15/2026
pgweb through 0.17.0 leaves the POST /api/connect endpoint unguarded when connect-backend authorization is configured, allowing attackers to supply arbitrary database connection strings. Attackers can bypass the resource-to-database mapping by providing a custom session identifier and connection URL to access unauthorized databases and internal services.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability in pgweb versions through 0.17.0 represents a critical authentication bypass that undermines the intended security model of database administration tools. While the application implements authorization mechanisms for its primary administrative interface, specifically targeting the connect-backend functionality to restrict which databases users can access based on predefined mappings, it fails to apply these same controls to all API endpoints. The specific flaw resides in the POST /api/connect endpoint, which is designed to establish new database connections within a session. In a properly secured implementation, this endpoint should validate that any requested connection string corresponds to an allowed resource as defined by the administrator's configuration. However, due to insufficient access control checks, this endpoint remains unguarded against unauthorized requests when connect-backend authorization is enabled for other parts of the application.
From a technical perspective, the core issue is a broken object level reference or improper restriction of functional flow within the API layer. The vulnerability allows an attacker to supply arbitrary database connection strings directly via HTTP POST requests. By manipulating the request parameters, specifically by providing a custom session identifier and a tailored connection URL, an adversary can bypass the resource-to-database mapping logic entirely. This means that even if the system is configured to only allow access to specific internal databases for certain user roles or groups, the attacker can circumvent these restrictions simply by forging the necessary request components. The lack of validation on the destination database host and credentials in this specific endpoint creates a direct path to unauthorized data exposure.
The operational impact of this vulnerability is severe, particularly in environments where pgweb is deployed as an internal tool for managing sensitive production databases. An attacker who gains access to the application interface or can interact with its API endpoints can potentially connect to any database reachable from the server hosting pgweb. This includes not only external third-party services but also critical internal infrastructure such as other microservices, legacy systems, and core business data repositories. The ability to establish unauthorized connections facilitates a range of malicious activities including data exfiltration, modification or destruction of records, and further lateral movement within the network by using the compromised database credentials as a foothold for additional attacks against backend services that trust the pgweb server's identity.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in restricting access to resources based on user roles or configuration settings. It also maps closely to MITRE ATT&CK techniques related to Initial Access and Credential Access, as it allows an attacker to leverage existing application credentials to reach unauthorized targets that were not intended for their level of privilege. The scenario exemplifies how partial implementation of security controls can create false confidence in system safety while leaving critical attack vectors open.
To mitigate this risk, immediate action is required to patch the pgweb installation to version 0.17.1 or later where these access control checks have been properly implemented across all relevant API endpoints. Administrators should ensure that connect-backend authorization rules are strictly enforced for every endpoint that initiates database connections, not just the primary web interface. In the interim before upgrading, network-level controls such as firewall rules restricting outbound traffic from the pgweb server to only necessary destinations can provide a layer of defense in depth. Additionally, implementing strict input validation and ensuring that all API endpoints undergo rigorous security testing for access control flaws is essential to prevent similar issues in future updates or related software components.