CVE-2017-9841: PHPUnit Command Injection Vulnerability

CVE-2017-9841 is a code-injection flaw in PHPUnit that lets a remote attacker run arbitrary PHP when a specific utility script is reachable over HTTP. It matters because PHPUnit is commonly installed as a development dependency and sometimes left inside web-accessible vendor directories; if that path is exposed, an unauthenticated request can lead to full remote code execution on the host.

Defenders should treat any internet-facing or broadly reachable copy of the affected script as high priority until it is removed or patched per the vendor advisory.

How it works

The weakness is CWE-94 (improper control of code generation / code injection). PHPUnit ships a helper script intended for internal test execution. When that script is reachable at a URI such as /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php, it processes HTTP POST body content. An attacker who can send a POST whose body begins with the substring "

No authentication is required once the file is exposed. The attack surface is therefore any site or application whose Composer (or similar) vendor tree is served by the web server and still contains the vulnerable PHPUnit utility. Exact exploit mechanics and affected release ranges must be confirmed against the vendor advisory; do not rely on secondary summaries alone.

Am I affected? How to find it in your systems

PHPUnit is a PHP testing framework normally installed via Composer into a project’s vendor directory. It is intended for development and CI, not production. In practice it appears on:

• Application servers and containers that deploy the full source tree, including vendor/
• Shared hosting or misconfigured document roots that map /vendor or /vendor/phpunit into the web space
• Legacy or hastily packaged images that never stripped dev dependencies

Inventory steps:

• Search filesystems and container images for the path fragment phpunit/phpunit/src/Util/PHP/eval-stdin.php (or the broader phpunit directory).
• Review web-server configurations and reverse-proxy rules for any Alias, location, or static-file mapping that could expose vendor/.
• Query package manifests (composer.lock, composer.json) and CI build logs for PHPUnit as a direct or transitive dependency; note whether it is declared under require-dev only.
• Scan external attack surface (or internal asset inventories) for HTTP responses that return the script or a PHP error when the eval-stdin.php URI is requested.

Telemetry signs of exploitation attempts include POST requests to URIs containing eval-stdin.php, especially those whose bodies start with "

How to remediate

Patch first: apply the updates published by the PHPUnit maintainers as instructed in the official vendor advisory and follow the CISA-required action to apply updates per vendor instructions. After updating, verify that the vulnerable script is no longer present or is no longer executable in any deployed artifact.

Additional hardening for this class of issue:

• Ensure production builds exclude require-dev packages (Composer --no-dev or equivalent).
• Configure the web server so that the vendor directory, or at least any phpunit paths, returns 403/404 and is never executed as PHP.
• Run application code with the least privileges necessary and keep document roots minimal.
• Add pipeline checks that fail the build if eval-stdin.php or similar test utilities appear in release artifacts.

If you can't patch immediately

Until the vendor update can be deployed, reduce exposure with compensating controls:

• Block or remove external (and unnecessary internal) access to any URI containing /vendor/phpunit or eval-stdin.php via web-server rules, WAF virtual patches, or network ACLs.
• Delete the eval-stdin.php file (and ideally the entire unused PHPUnit tree) from production hosts if testing functionality is not required there.
• Segment application hosts so that even successful code execution has limited reach to data stores and admin networks.
• Increase monitoring for POSTs to the known path, unexpected PHP execution, and anomalous child processes; alert and investigate promptly.
• If a WAF is available, add a temporary rule that rejects request bodies beginning with "

These measures lower risk but do not replace installing the vendor fix.

If your data may have been exposed

Actively exploited remote-code-execution vulnerabilities are frequently used to establish persistence, steal credentials, or stage further compromise; ransomware use of this specific CVE is not documented, yet any successful exploitation should be treated as a potential breach. Perform standard incident-response steps: isolate affected hosts, preserve logs, rotate secrets that may have been accessible to the web-server user, and examine the environment for webshells or lateral movement. You can also run a free exposure scan of your email addresses against known breach data sets to see whether associated credentials have appeared in prior incidents, then force password resets and enable multi-factor authentication where appropriate.