Stored cross-site scripting in pgAdmin 4's error-rendering and plan-node-rendering paths. Text returned by a PostgreSQL server (ErrorResponse messages, including object names quoted back inside relation-does-not-exist errors and inside EXPLAIN Recheck Cond / Exact Heap Blocks fields) was passed verbatim through html-react-parser at every user-facing sink — the notifier toasts, FormFooterMessage / FormInput help and error areas, FormNote, ModalProvider AlertContent and confirmDelete, ToolErrorView, the Explain visualiser's NodeText panel, the SQL editor confirm dialogs, ConfirmSaveContent, PreferencesHelper modal alerts, and SelectThemes helper text. A PostgreSQL server an attacker controls — or any server returning attacker-influenced text such as a table or column name a low-privilege database user can create — could inject arbitrary HTML (including <iframe>) into the pgAdmin DOM the moment the victim's pgAdmin connected to that server or viewed an Explain plan that referenced the crafted object.
The injected iframe's srcdoc could fetch attacker-served JavaScript and, by writing to parent.location, redirect the victim's top-level pgAdmin browser tab to an attacker-controlled URL. Because the injection originates from inside pgAdmin's own interface, standard anti-clickjacking controls (X-Frame-Options, Content-Security-Policy: frame-ancestors) do not mitigate it. A phishing page rendered inside the legitimate pgAdmin window is indistinguishable from a genuine pgAdmin dialog.
Fix combines three complementary layers. (1) DOMPurify sanitisation is wrapped around every html-react-parser call site reachable from notifier, alert, form-error, Explain, and SQL-editor flows. (2) A new plain-text rendering contract — SafeMessage / SafeHtmlMessage components plus Notifier.errorText / alertText / warningText / infoText / successText helpers — is introduced; around fifty callers across browser, tools, dashboard, debugger, misc, llm, preferences, schema diff, and the SQL editor that previously interpolated backend-derived strings are migrated to the plain-text variants. (3) Backend HTML-escape is applied at the post-connection-SQL handler (execute_post_connection_sql) via a new sanitize_external_text helper, so third-party JSON consumers (audit logs, API clients) never receive raw markup either; the Explain plan-info renderer is also patched to _.escape Recheck Cond and Exact Heap Blocks at construction (matching every sibling field), giving defence in depth even before DOMPurify runs.
This issue affects pgAdmin 4: from 6.0 before 9.16.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N
CVSS Score: 9.3
An attacker who controls (or has write access to) content a PostgreSQL server returns -- ErrorResponse text, quoted object names inside relation-does-not-exist errors, EXPLAIN Recheck Cond / Exact Heap Blocks fields -- crafts HTML containing an iframe whose srcdoc executes attacker JS. When a pgAdmin user connects to that server (or views an Explain plan referencing the crafted object), the attacker HTML is rendered in the pgAdmin UI.
Why C:H/I:H (not L/L): pgAdmin's default Content-Security-Policy carries 'unsafe-inline' and 'unsafe-eval' so it does not constrain script execution; an iframe rendered via the srcdoc attribute inherits the embedding origin, so the attacker JS runs same-origin to the victim's authenticated pgAdmin session. From there the attacker can read every saved server connection credential (high confidentiality) and issue arbitrary SQL against every server the victim is connected to (high integrity), via pgAdmin's own API with the user's CSRF token. This is the confused-deputy pattern -- third-party content drives the victim admin -- so S:C is straightforward. A:N because the primary impact is data exfil / takeover, not denial of service.
| Attack Vector |
Network |
Scope |
Changed |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
Required |
Availability Impact |
None |
An attacker who controls (or has write access to) content a PostgreSQL server returns -- ErrorResponse text, quoted object names inside relation-does-not-exist errors, EXPLAIN Recheck Cond / Exact Heap Blocks fields -- crafts HTML containing an iframe whose srcdoc executes attacker JS. When a pgAdmin user connects to that server (or views an Explain plan referencing the crafted object), the attacker HTML is rendered in the pgAdmin UI.
Why C:H/I:H (not L/L): pgAdmin's default Content-Security-Policy carries 'unsafe-inline' and 'unsafe-eval' so it does not constrain script execution; an iframe rendered via the srcdoc attribute inherits the embedding origin, so the attacker JS runs same-origin to the victim's authenticated pgAdmin session. From there the attacker can read every saved server connection credential (high confidentiality) and issue arbitrary SQL against every server the victim is connected to (high integrity), via pgAdmin's own API with the user's CSRF token. This is the confused-deputy pattern -- third-party content drives the victim admin -- so S:C is straightforward. A:N because the primary impact is data exfil / takeover, not denial of service.
CVSS 3.1