Vendor Phpunit Phpunit Src Util Php Eval-stdin.php Cve Upd May 2026

The text you're looking for refers to CVE-2017-9841 , a critical remote code execution (RCE) vulnerability in This vulnerability exists in the eval-stdin.php file, which is often found at paths like: /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php /vendor/phpunit/phpunit/Util/PHP/eval-stdin.php National Institute of Standards and Technology (.gov) How it Works The script was designed to process raw POST data using eval('?>' . file_get_contents('php://input'));

. Because it does not require authentication or perform input validation, an attacker can send a HTTP POST request

containing malicious PHP code to the server and execute it remotely. Miggo Security Affected Versions

A PoC exploit for CVE-2017-9841 - PHPUnit Remote Code ... - GitHub

The specific query refers to a well-known vulnerability in PHPUnit, a popular unit testing framework for PHP. The file path vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php is associated with CVE-2017-9841.

Below is a detailed breakdown of this CVE, its impact, exploitation, and remediation.

Chronicle: Systematic analysis and actionable guidance — vendor/phpunit/phpunit src/Util/PHP/eval-stdin.php CVE

Summary

File of interest: vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
Issue class: Improper handling of arbitrary PHP code passed to an eval-like runtime path, enabling remote code execution (RCE) when untrusted input is evaluated.
Common CVE context: Several CVEs have historically impacted phpunit’s eval utilities (e.g., CVE-2021-xxxx style RCEs); treat this as an RCE vector requiring immediate mitigation.

Technical root cause (systematic)

Purpose of file: eval-stdin.php is intended to read PHP code from STDIN and execute it (typically used in test harnesses).
Dangerous behavior: It accepts and executes PHP code provided via STDIN without adequate authentication, input validation, or environment restriction.
Attack surface:
- Composer-installed vendor directory often gets shipped into production or CI images.
- Attackers who can pass data to STDIN (e.g., via HTTP endpoints, CLI wrappers, CI job inputs, or misconfigured container/docker build steps) can execute arbitrary PHP code.
- Web-accessible copies of this file (e.g., if vendor/ is exposed by a webserver) allow remote invocation.
Preconditions for exploitation:
- The file is present in the deployed environment.
- There exists a channel for an attacker to provide STDIN to PHP process invoking that script (or the file is reachable via web and executed by PHP).
- The environment runs PHP with privileges sufficient to make the exploit impactful.

Practical impact

Full arbitrary code execution as the user running PHP (RCE).
Data exfiltration, integrity loss, pivoting to other services, deployment of backdoors.
Severity: High — RCE in test utility shipped to production is critical.

Indicators of presence / detection

Presence of vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php on disk in production or CI images.
Unexpected PHP processes that read from STDIN or spawn shells.
Logs or audit trails showing execution of eval-stdin.php or execution of php -r or php < vendor/phpunit/.../eval-stdin.php.
File modification times inconsistent with deployments.
Unexpected network connections from PHP processes after test artifact installation.

Actionable mitigation steps (immediate to medium-term) Immediate (apply at once)

Remove the file from any production or internet-facing deployments:
- Delete vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php from deployed artifacts.
- If you deploy via Composer, add a post-install/remove script to delete the path or exclude dev dependencies from production installs.
Ensure composer install in production uses --no-dev and composer.lock from CI builds: composer install --no-dev --optimize-autoloader.
If vendor directories are served by a webserver, block access (deny or remove). Configure webserver to disallow serving anything under vendor/.
If you suspect compromise, isolate affected hosts and perform forensic capture of memory, process lists, and network activity.

Short term (hours–days)

Scan systems and Docker images for presence of eval-stdin.php:
- Locally: find / -path '*/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php' -print
- In images: docker run --rm imagename sh -c "find / -name eval-stdin.php"
Rotate credentials and secrets that may be exposed on affected hosts.
Check CI pipelines for steps that expose STDIN inputs or echo artifacts into php invocations.

Medium term (days–weeks)

Harden deployment pipeline:
- Never include dev dependencies in production artifacts.
- Use artifact-building where only required runtime files are packaged.
Implement file integrity monitoring (FIM) to detect unexpected files under vendor/.
Run vulnerability scanning on containers and repos (SCA tools that detect vendor CVEs).
Add runtime restrictions: run PHP in containers with least privilege; enable process/file access controls (AppArmor/SELinux).

Long term (weeks–months)

Treat vendor/ as untrusted — audit third-party test tooling before packaging.
Adopt secrets management and ephemeral credentials to limit blast radius.
Enforce automated builds that strip/test-only helpers from release artifacts.

Remediation & patching

Update phpunit to a non-vulnerable release if patch/release exists; consult phpunit release notes and changelogs.
If update not possible, remove or neutralize the file in build artifacts (e.g., delete or replace its contents with a safe stub).
Verify the fix by redeploying and rescanning images.

Post-incident validation

Validate that eval-stdin.php is absent from all production systems and images.
Confirm no unexpected cronjobs, webhooks, or CI steps were added.
Re-run SCA and container scans showing no vulnerable phpunit utility present.
Monitor for anomalous PHP process behavior and external communications for at least 30 days.

Example safe-removal commands

Unix shell (delete all instances):
- find . -path "*/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php" -exec rm -f {} ;
Docker image cleanup (rebuild images without dev deps):
- In Dockerfile, use multi-stage build and install dev deps only in build stage; copy only runtime files into final image.

Recommended detection queries (SIEM)

Search for process execution patterns:
- Command line contains "vendor/phpunit" or "eval-stdin.php"
- PHP processes started with input redirection or suspicious -r / -B usage
Network: outgoing connections initiated by webserver or php-fpm not expected in baseline.

Quick risk triage matrix (concise)

Present in production AND web-accessible: Critical — immediate removal and investigation.
Present in production but not web-accessible: High — remove and verify CI/pipeline inputs.
Present only in local dev machines: Low — remove from artifacts before release.

Communication checklist for stakeholders

Ops: Remove file from prod, rebuild images, apply firewall/webserver rules.
Dev: Ensure composer --no-dev release process; add CI checks.
Security: Scan, investigate signs of compromise, rotate secrets if needed, notify affected parties.

If you want, I can:

produce shell scripts to scan and remove instances across servers,
provide a CI/CD snippet to exclude dev deps and strip files,
draft a short incident notification for internal teams.

Date: March 23, 2026.

CVE-2017-9841 is a critical remote code execution (RCE) vulnerability in the PHPUnit testing framework. It allows unauthenticated attackers to execute arbitrary PHP code on a server if the PHPUnit source files are publicly accessible. Vulnerability Breakdown Path: vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php.

Root Cause: The script originally used eval('?> ' . file_get_contents('php://input')); to process input. php://input reads raw data from an HTTP POST request. eval() then executes that data as PHP code.

Exploitation: Attackers send a HTTP POST request to the vulnerable file with a payload beginning with . Since no authentication is required, they can gain full control of the application context. Affected Versions PHPUnit 4.x: Versions prior to 4.8.28. PHPUnit 5.x: Versions prior to 5.6.3. How to Fix


Update PHPUnit: Upgrade to at least version 4.8.28 or 5.6.3. The patch replaced php://input with php://stdin, which cannot be accessed via web requests.
Clean Production: Run composer install --no-dev to ensure development tools like PHPUnit are never deployed to production.
Restrict Access: If you cannot update immediately, block access to the /vendor directory in your web server configuration (e.g., Nginx or Apache). 
Despite being an older vulnerability, it remains a frequent target for automated scanners and botnets like Androxgh0st because many legacy systems still have exposed /vendor directories.      
CVE-2017-9841 is a high-severity 9.8 Critical Remote Code Execution (RCE) vulnerability in PHPUnit, a popular testing framework for PHP applications. Despite being years old, it remains a frequent target for automated scanners and botnets because it targets misconfigured production environments where development tools are accidentally exposed. The Core Flaw: eval-stdin.php
The vulnerability resides in the file vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php. This script was designed to allow PHPUnit to execute code passed through standard input (stdin) for internal testing purposes. vendor phpunit phpunit src util php eval-stdin.php cve
The original code used a dangerous combination of functions: eval('?> ' . file_get_contents('php://input'));  Use code with caution. Copied to clipboard
php://input: This stream allows a script to read raw data from the body of an HTTP POST request.
eval(): This function executes any string passed to it as PHP code.
By sending a standard HTTP POST request to this file, an unauthenticated attacker could include arbitrary PHP code in the request body. If the payload began with the  tag, the server would execute it immediately, granting the attacker full control over the application environment. Impact and Exposure

Successful exploitation allows attackers to perform highly damaging actions, such as:
Based on the keywords provided, you are referring to a specific security vulnerability in PHPUnit involving the file phpunit/src/Util/PHP/eval-stdin.php.
Here are the details regarding this issue:
8. Remediation Steps


Update PHPUnit (if used in production – which it shouldn’t be):
composer require --dev phpunit/phpunit:^5.6.3



Remove PHPUnit from production entirely:
composer install --no-dev



Block access to /vendor/ via web server configuration: The text you're looking for refers to CVE-2017-9841

Apache (.htaccess):
<Directory "vendor">
    Require all denied
</Directory>


Nginx:
location ~ /vendor/ 
    deny all;
    return 403;





Scan for backdoors if the server was previously vulnerable.


The Root Cause: eval-stdin.php
Let's examine the original vulnerable source code of eval-stdin.php:
<?php
// Original vulnerable code (simplified)
eval('?>'.file_get_contents('php://input'));

That’s it. Just two lines.
What does it do?

file_get_contents('php://input') reads the raw HTTP POST body.
The script then prepends ?> (a PHP closing tag) to the raw input and passes the entire string to eval().

The critical mistake: The eval() construct executes any string as PHP code. The ?> tag is a trick to escape from PHP mode, but the net result is catastrophic: any HTTP POST data sent to this script is executed as PHP.
4. Scope of Impact
This vulnerability is notorious not because PHPUnit is insecure software, but because it is ubiquitous.

Widespread Usage: PHPUnit is the standard testing framework for PHP. Millions of projects, including major CMS platforms (Drupal, Joomla, WordPress plugins) and frameworks (Laravel, Symfony), include it in their development dependencies.
Supply Chain Risk: Even if an application's own code is secure, the presence of this file in a default Composer installation creates a vector for "supply chain" attacks if the server configuration is lax.

What is CVE-2017-9841?
Severity: Critical (CVSS 9.8)

Affected versions: PHPUnit ≤ 4.8.28 and ≤ 5.6.3

Fixed in: PHPUnit 4.8.28, 5.6.3, and later
Conclusion: A Cautionary Tale of Two Lines
The file vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php is a perfect storm: a unit testing utility, a missing --no-dev flag, and a web-accessible vendor directory. CVE-2017-9841 turned two lines of code into a universal RCE gadget for hundreds of thousands of applications.
As a developer, the lesson is simple: treat your vendor/ directory like a loaded weapon in production. Never routable, never directly accessible. As a security professional, never underestimate the power of simple file existence checks—sometimes the smallest file delivers the biggest breach.