Summary
Google::Auth for Perl can execute a command specified in an external-account credentials JSON file without requiring an explicit opt-in. When an application loads credentials from a configuration it does not fully control, an attacker may achieve operating-system command execution with the application's privileges.
Affected context
The issue affects Google::Auth configurations that use the external-account credential flow with a credential_source.executable entry. The executable command and environment variables are read from the credentials JSON, and the command is invoked without a user-controlled safety gate. Configurations without this executable credential source do not select the affected code path.
Exploit preconditions
- Attack surface: Application Default Credentials processing through Google::Auth
- Required access: Ability to supply, alter, or influence the credentials JSON consumed by the application
- Trigger point: Credential construction when an external-account configuration contains
credential_source.executable - Why exploitation is possible: The configured command is passed to a shell through a single-argument
systemcall, while attacker-influenced environment variables are copied into the process environment
Why this happens
The vulnerability results from treating a command supplied through an external configuration file as executable functionality without an explicit security boundary or opt-in control. A single-argument system invocation delegates interpretation of the complete string to /bin/sh, allowing command syntax in the configuration to affect process execution. This maps primarily to CWE-78: Improper Neutralization of Special Elements used in an OS Command, with CWE-829: Inclusion of Functionality from Untrusted Control Sphere also relevant because executable behavior is sourced from externally controlled configuration.
Potential impact
- An attacker may execute operating-system commands as the application process
- Application credentials, tokens, and locally accessible data could be exposed
- The host or container may be modified or used for persistence
- Compromised execution could enable lateral movement or supply-chain abuse
General mitigation guidance
Mitigation generally focuses on preventing configuration data from defining executable behavior and reducing trust in external credential files.
Common defensive patterns include:
- Disable executable credential sources unless they are explicitly required and independently approved
- Use credential flows that contain data rather than commands
- Treat credential configuration as security-sensitive, immutable input
- Apply strict schema and policy validation that rejects executable entries and unexpected environment variables
- Avoid shell-mediated command construction; where a narrowly defined subprocess is necessary, use a fixed executable and an argument array
- Run applications with least privilege and isolate credential-processing workloads
- Restrict access to credential files, environment variables, and application identities
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis rules for single-string
systemcalls and other shell-spawning APIs - Code review checks for command, executable, or environment-variable fields sourced from configuration
- Repository and deployment scans for external-account JSON containing
credential_source.executable - Policy enforcement that rejects credential configurations capable of launching arbitrary processes
- Runtime monitoring for unexpected child processes, shell invocation, or unusual environment changes during authentication
Automated code review and software composition analysis tools may help surface unsafe command-execution patterns.
