Summary
A command injection flaw in pgAdmin 4's MASTER_PASSWORD_HOOK allowed attacker-controlled usernames containing shell metacharacters to be embedded directly into a command string executed with a shell.
In deployments where the hook string uses %u and usernames originate from external authentication sources, an authenticated user could execute arbitrary commands as the pgAdmin service account.
Affected context
This vulnerability occurs in pgAdmin 4 deployments that enable the MASTER_PASSWORD_HOOK setting and configure a hook string containing the %u placeholder.
It is most relevant where user identities are sourced from external authentication providers (such as OAuth/OIDC, Kerberos, or webserver-based auth), and pgAdmin does not fully constrain or normalize the resulting usernames.
In such configurations, the hook command is constructed from a trusted administrator-defined template but is unsafe when the untrusted username is interpolated directly and executed via a system shell.
Exploit preconditions
- Attack surface: Web interface or API where users authenticate to pgAdmin 4.
- Required access: Ability to authenticate and obtain a username value that is accepted by pgAdmin (including from external auth sources).
- Trigger point: Invocation of MASTER_PASSWORD_HOOK, where the %u placeholder in the configured command string is replaced with the current username and executed.
- Why exploitation is possible: The previous implementation formed a command string by concatenating the administrator-defined hook with the raw username and executed it using
subprocess.Popen(..., shell=True), allowing shell metacharacters in the username to be interpreted by the shell as part of the command.
Why this happens
The underlying bug is unsafe construction and execution of shell commands with untrusted data.
Instead of treating the administrator-configured hook string as a fixed argument vector and confining user-controlled data to a single argument, the code interpolated the username directly into a shell command line and executed it with shell=True.
This maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), and is closely related to CWE-88: Argument Injection or Modification, since untrusted input is allowed to alter the effective arguments and behavior of the invoked process.
Potential impact
- Authenticated users may execute arbitrary OS commands as the pgAdmin service account.
- Attackers could read or modify database connection data managed by pgAdmin.
- Local files accessible to the pgAdmin service account could be exfiltrated or altered.
- The host running pgAdmin may be used as a pivot for further lateral movement.
- Application integrity and confidentiality of stored credentials may be compromised.
General mitigation guidance
Mitigation typically involves eliminating direct shell interpretation of untrusted data and treating user-controlled fields as opaque arguments.
Common defensive patterns include:
- Constructing command invocations as explicit argument lists and using
shell=False(or equivalent) so that operating system shells are not involved. - Ensuring that placeholders like %u are substituted only into individual argument elements, never into whole shell command lines.
- Normalizing or restricting usernames to a safe character set when they are used in security-sensitive integrations.
- Designing hooks and integrations such that any complex logic (piping, redirection, environment expansion) resides inside scripts, not in dynamically assembled command strings.
- Running service components with least-privilege accounts to limit the damage if a hook is misconfigured or abused.
How teams detect issues like this
High-level detection approaches include:
- Static analysis rules that flag use of
subprocess(or similar APIs) withshell=Trueand dynamic string concatenation involving user or externally sourced data. - Code review checklists that require argument-vector based process execution and ban placeholder substitution into shell command lines.
- Configuration audits focusing on hooks, integration scripts, and any settings that build commands from user-related fields.
- Policy enforcement within CI/CD pipelines to prevent merging changes that introduce shell-based execution paths with untrusted input interpolation.
- Optional use of automated security scanners that specifically look for CWE-78 and CWE-88 patterns in application code and configuration logic.
