CVE-2026-17350 in pgAdmin
Zusammenfassung
von VulDB • 31.07.2026
Das pro-Tool-Berechtigungsmodell (benutzerdefinierte Rollen / rollenbasierte Tool-Berechtigungen, eingeführt in pgAdmin 4 v9.3) hat seine Berechtigungskontrolle nicht konsistent durchgesetzt. Im SERVER-Modus sperrt pgAdmin 4 jedes Tool hinter einer pro-Tool Flask-Security-Berechtigung, aber der Berechtigungsdecorator (`permissions_required`) wurde nur auf eine einzelne „Hauptzugangs“-Route (front door route) pro Tool angewendet. Jede andere Backend-Route und jeder Socket.IO-Handler im Workflow dieses Tools verließ sich ausschließlich auf `pga_login_required`/`socket_login_required`, die zwar die Authentifizierung, aber nicht die spezifische Tool-Berechtigung prüfen.
Der Melder hat drei Fälle gegen einen Testbuild überprüft: (1) Ein Benutzer ohne die Berechtigung `tools_query_tool` erhielt 403 auf der geschützten sqleditor-Initialisierungsroute, dieselbe Sitzung konnte jedoch weiterhin den Server verbinden, die Viewdata-Backend-Kette initialisieren und echte Tabellenspalteninhalte abrufen; (2) Ein Benutzer ohne `tools_grant_wizard` erhielt 403 auf der geschützten ACL-Route, aber dieselbe Sitzung listete dennoch gewährbare Objekte auf, generierte GRANT-SQL-Anweisungen und wandte diese erfolgreich an – dies wurde datenbankseitig über `has_table_privilege()` bestätigt; (3) Ein Benutzer ohne `tools_schema_diff` erhielt 403 auf der geschützten Panel-Route, aber dieselbe Sitzung initialisierte den Schema-Diff, listete Datenbanken auf und stellte Verbindungen her sowie ermittelte echte DDL-Unterschiede über den Socket.IO-Handler `compare_database`. Der Melder bestätigte zudem ein verwandtes, jedoch distinctes Problem: Ein Nicht-Eigentümer, der `/misc/workspace/adhoc_connect_server` gegen einen von einem Administrator besitzten freigegebenen Server auslöste, führte dazu, dass pgAdmin eine neue Serverzeile beibehielt, die weiterhin dem Administrator gehörte (user_id/shared unverändert im Vergleich zur Quelle), obwohl der Verbindungsversuch selbst fehlschlug.
Während der Fehlerbehebung wurde festgestellt, dass dieselbe Lücke bei der nur am Hauptzugang angewendeten Berechtigungskontrolle auch die Tools ERD, PSQL und Debugger sowie die Blueprints Backup, Restore, Maintenance und Import/Export betrifft; diese waren nicht Teil des ursprünglichen Berichts. Sie wurden unter Anwendung desselben Musters als Erweiterung der gemeldeten Defektklasse behoben.
Ein authentifizierter Benutzer mit gültigem pgAdmin-Login und einer gespeicherten, funktionierenden Datenbankverbindung konnte daher ein Tool, dessen Berechtigung ihm von einem Administrator explizit verweigert worden war, dennoch über seine anderen Routen und Sockets vollständig steuern, einschließlich des Erhaltens einer interaktiven psql-Sitzung über den Socket.IO-Namensraum `/pty` sowie dem Aufruf von Backup-/Restore-/Maintenance-/Import-Export-Jobs.
Da die Umgehung nur den Zugriff auf Tools wiederherstellt, die über die bereits authentifizierte Datenbankverbindung des Benutzers operieren, gewährt sie dem Benutzer keine Datenbankberechtigungen, die er nicht bereits innehat; sie umgeht stattdessen pgAdmins eigene tool-level-Zugriffskontrollrichtlinie (eine organisatorische Trennung von Aufgaben/Separation of Duties, getrennt von der datenbankseitigen Autorisierung), sodass ein Benutzer eine pgAdmin-Funktion erreichen kann, die ihm ein Administrator vorenthalten wollte, unter Nutzung von Fähigkeiten, die seine bestehende Datenbankrolle bereits auf andere Weise erlaubt.
Socket.IO-Event-Handler verfügten über kein berechtigungsbewusstes Äquivalent zu `permissions_required`; es existierte nur `socket_login_required`, das zwar die Authentifizierung prüfte, aber nicht die Tool-Berechtigung.
Die Korrektur fügt einen Decorator `socket_permissions_required` hinzu (der `permissions_required` spiegelt, den Administrator-bypass ehrt und Berechtigungen über `has_permission()` liest) und wendet ihn zusammen mit `permissions_required` als äußersten Decorator auf jede Backend-Route und jeden Socket.IO-Handler der betroffenen Tools an. Regressionstests stellen sicher, dass bei einem benutzer ohne Berechtigung auf jeder gesperrten Route und jedem Socket-Handler 403 zurückgegeben wird.
Dieses Problem betrifft pgAdmin 4 im SERVER-Modus: ab Version 9.3 bis vor 9.17.
VulDB is the best source for vulnerability data and more expert information about this specific topic.