PHP_CodeSniffer gitblame report command injection via crafted filenameGHSA-hmqg-cxww-wqhq
Fix: PHPCSStandards/PHP_CodeSniffer#1473GHSA-hmqg-cxww-wqhq is a OS Command Injection vulnerability in squizlabs/php_codesniffer. A fix is available for squizlabs/php_codesniffer — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-hmqg-cxww-wqhq.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
squizlabs/php_codesniffer🐘squizlabs/php_codesnifferReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
PHP_CodeSniffer versions before v3.13.6 and v4.0.2 contain a command injection vulnerability in the code creating the Gitblame, Hgblame and Svnblame report(s).
As a result, running PHP_CodeSniffer over untrusted files, for example, in a CI pipeline that scans pull requests, or on a developer machine reviewing third-party code, could result in attacker-controlled shell commands being executed when the Gitblame, Hgblame or Svnblame report(s) would process a file whose name contains shell metacharacters.
- Users using the default
Fullreport, or any of the other non-*blame reports, are not affected. - Users on a runtime platform which does not allow filenames to contain shell metacharacters, such as
"and;, are not affected.
Patched versions
The issue has been fixed in PHP_CodeSniffer v3.13.6 and v4.0.2. We recommend all users upgrade to these versions at their earliest convenience.
Workaround
Users of PHP_CodeSniffer who cannot upgrade immediately should ensure they do not use the Gitblame, Hgblame or the Svnblame reports when scanning untrusted code.
This is especially relevant for CI jobs, pre-commit or review tooling, automated review services, and any service that scans untrusted repositories or uploaded source trees.
Credits
Many thanks to both @Faze-up and @edorian for responsibly disclosing this vulnerability.
How can I report a security bug?
Please report security vulnerabilities privately via the "Security and quality" tab on the PHP_CodeSniffer repository.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | squizlabs/php_codesniffer | all versions | 3.13.6composer require squizlabs/php_codesniffer:^3.13.6 |
| 🐘Packagist | squizlabs/php_codesniffer | ≥ 4.0.0&&< 4.0.2 | 4.0.2composer require squizlabs/php_codesniffer:^4.0.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for squizlabs/php_codesniffer, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update squizlabs/php_codesniffer to 3.13.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hmqg-cxww-wqhq is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is GHSA-hmqg-cxww-wqhq in your dependencies?
Find it across Packagist, including transitive dependencies.