Summary
PHPCSUtils evaluates attacker-controlled PHP array-key expressions with eval(), allowing code embedded in scanned source to run during analysis. When an extending sniff processes untrusted PHP code through affected array-key handling paths, an attacker may execute arbitrary commands on the scanning host.
PHPCSUtils evaluates attacker-controlled PHP array-key expressions with eval(), allowing code embedded in scanned source to run during analysis. When an extending sniff processes untrusted PHP code through affected array-key handling paths, an attacker may execute arbitrary commands on the scanning host.
Affected context
The vulnerability occurs in PHPCSUtils versions that use AbstractArrayDeclarationSniff::getActualArrayKey() to evaluate array-key expressions. It becomes risky when a scanning workflow analyzes untrusted PHP source and uses reachable sniff paths such as Universal.Arrays.DuplicateArrayKey or Universal.Arrays.MixedArrayKeyTypes.
The vulnerability occurs in PHPCSUtils versions that use AbstractArrayDeclarationSniff::getActualArrayKey() to evaluate array-key expressions. It becomes risky when a scanning workflow analyzes untrusted PHP source and uses reachable sniff paths such as Universal.Arrays.DuplicateArrayKey or Universal.Arrays.MixedArrayKeyTypes.
Exploit preconditions
- Attack surface: PHP source-code scanning and linting workflows
- Required access: Ability to submit, modify, or cause untrusted PHP code to be scanned
- Trigger point: Processing of attacker-controlled array-key expressions by an extending sniff
- Why exploitation is possible: The scanner evaluates expressions through
eval(), causing embedded callback-form keys or other executable expressions to run with the scanner's privileges
- Attack surface: PHP source-code scanning and linting workflows
- Required access: Ability to submit, modify, or cause untrusted PHP code to be scanned
- Trigger point: Processing of attacker-controlled array-key expressions by an extending sniff
- Why exploitation is possible: The scanner evaluates expressions through
eval(), causing embedded callback-form keys or other executable expressions to run with the scanner's privileges
Why this happens
The underlying issue is the use of dynamic PHP evaluation to determine the value of an array key. Calling eval() on source-derived expressions treats scanned input as executable code rather than inert syntax, which maps to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code.
The underlying issue is the use of dynamic PHP evaluation to determine the value of an array key. Calling eval() on source-derived expressions treats scanned input as executable code rather than inert syntax, which maps to CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code.
Potential impact
- An attacker may execute arbitrary commands on the scanning host.
- Credentials, source code, or build artifacts could be exposed.
- The scanning environment could be modified or disrupted.
- Compromised analysis jobs could affect downstream CI/CD systems.
- An attacker may execute arbitrary commands on the scanning host.
- Credentials, source code, or build artifacts could be exposed.
- The scanning environment could be modified or disrupted.
- Compromised analysis jobs could affect downstream CI/CD systems.
General mitigation guidance
Mitigation generally focuses on eliminating dynamic evaluation of source-derived expressions and reducing trust in analyzed code.
Common defensive patterns include:
- Replacing
eval()with parser-based, non-executing syntax analysis. - Treating array-key expressions as data and evaluating only narrowly defined, safe constructs where necessary.
- Running scanners with least-privilege operating-system accounts and isolated, disposable environments.
- Restricting network access, filesystem permissions, and secret availability for analysis jobs.
- Applying trust and provenance policies before untrusted code enters automated scanning workflows.
Mitigation generally focuses on eliminating dynamic evaluation of source-derived expressions and reducing trust in analyzed code.
Common defensive patterns include:
- Replacing
eval()with parser-based, non-executing syntax analysis. - Treating array-key expressions as data and evaluating only narrowly defined, safe constructs where necessary.
- Running scanners with least-privilege operating-system accounts and isolated, disposable environments.
- Restricting network access, filesystem permissions, and secret availability for analysis jobs.
- Applying trust and provenance policies before untrusted code enters automated scanning workflows.
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis rules that flag
eval()and other dynamic execution APIs. - Code review checks for execution of source text during parsing or linting.
- Dependency and call-graph analysis to identify scanner extensions that process untrusted code.
- CI policies that prohibit dynamic evaluation in analysis tooling.
- Runtime monitoring for unexpected child processes, command execution, or filesystem changes from scanning jobs.
Organizations can identify this class of issue through:
- Static analysis rules that flag
eval()and other dynamic execution APIs. - Code review checks for execution of source text during parsing or linting.
- Dependency and call-graph analysis to identify scanner extensions that process untrusted code.
- CI policies that prohibit dynamic evaluation in analysis tooling.
- Runtime monitoring for unexpected child processes, command execution, or filesystem changes from scanning jobs.
