PHP 8.1.0-dev User-Agentt Backdoor Remote Code Execution (RCE)

Severity: Critical (CVSS Equivalent: 10.0)

Vulnerability Type: Supply Chain Backdoor / Remote Code Execution (RCE)

Affected Software: PHP 8.1.0-dev (Development Build Only)

Attack Vector: Remote (Unauthenticated)

Authentication Required: No

User Interaction: None

Impact: Complete System Compromise

Overview

The PHP 8.1.0-dev User-Agentt Backdoor is one of the most infamous supply chain compromises in open-source software history. Unlike traditional vulnerabilities that arise from programming mistakes, this issue resulted from malicious code being intentionally inserted into the official PHP source code repository.

The backdoor appeared in development snapshots of PHP 8.1.0-dev during March 2021 after attackers successfully compromised the PHP Git infrastructure. The malicious commits impersonated trusted PHP maintainers and introduced a hidden mechanism capable of executing arbitrary PHP code whenever a specially crafted HTTP header was received.

Although the backdoor existed only briefly before being discovered and removed, any server that deployed one of the compromised development builds became instantly vulnerable to unauthenticated Remote Code Execution (RCE).

This incident fundamentally changed PHP's development workflow and ultimately led to the migration of the PHP source repository away from its self-hosted Git infrastructure. :contentReference[oaicite:0]{index=0}

Why This Vulnerability Is Unique

Most Remote Code Execution vulnerabilities originate from:

• Buffer overflows
• Input validation mistakes
• Memory corruption
• Logic flaws

This vulnerability was different.

It was not a coding bug.

It was a deliberately planted backdoor hidden inside legitimate PHP source code.

Instead of exploiting an existing weakness, attackers modified PHP itself to execute arbitrary PHP code supplied by anyone making an HTTP request.

That makes this incident one of the best-known examples of a software supply chain attack.

Background

On March 28, 2021, two suspicious commits appeared within PHP's Git repository.

Both commits appeared to come from well-known PHP maintainers.

Initially they looked harmless.

The commit messages resembled ordinary typo fixes.

However, researchers quickly noticed suspicious code added to the PHP interpreter.

The inserted code searched incoming HTTP requests for a custom header:

User-Agentt

Notice the extra "t".

This subtle spelling difference helped hide the backdoor during casual review.

If the header began with the trigger string:

zerodium

PHP would immediately execute everything following it using:

zend_eval_string()

This effectively allowed anyone to execute arbitrary PHP code remotely.

The malicious commits were removed within hours after discovery. Investigation later indicated the attackers had compromised the PHP Git infrastructure rather than legitimately obtaining maintainer signing keys. :contentReference[oaicite:1]{index=1}

Root Cause

The inserted code roughly performed the following logic:

Incoming HTTP Request
          │
          ▼
Read User-Agentt Header
          │
          ▼
Does header start with "zerodium"?
          │
      Yes ▼
Execute remaining text as PHP
          │
          ▼
Attacker gains Remote Code Execution

Instead of treating the header as harmless metadata, PHP evaluated it directly as executable PHP code.

Technical Breakdown

Normally an HTTP request contains headers similar to:

GET / HTTP/1.1

Host: example.com

User-Agent: Mozilla Firefox

The compromised PHP version additionally processed:

User-Agentt:

If its value started with:

zerodium

PHP called:

zend_eval_string()

The remaining content became executable PHP.

Conceptually:

User-Agentt:

zerodium
        │
        ▼
zend_eval_string(payload)
        │
        ▼
Remote Code Execution

Attack Flow

Attacker
    │
    │ HTTP Request
    ▼

GET /

User-Agentt: zerodiumsystem("id");

    │
    ▼

PHP 8.1.0-dev

    │
    ▼

Backdoor Triggered

    │
    ▼

system("id")

    │
    ▼

Command Executed

    │
    ▼

Output Returned

No authentication.

No session.

No credentials.

One HTTP request was enough.

Why "User-Agentt"?

The attackers intentionally chose

User-Agentt

instead of

User-Agent

because:

• it looked almost identical
• it would evade casual review
• most developers ignore unknown HTTP headers
• existing applications would continue working normally

This tiny typo concealed a complete remote code execution backdoor.

Affected Versions

Only:

PHP 8.1.0-dev

Specifically the compromised development snapshots published during the March 2021 incident.

Stable releases such as:

• PHP 7.x
• PHP 8.0
• PHP 8.1 Stable

were never affected.

Attack Requirements

The attacker only needed:

• Network access
• HTTP connectivity
• A vulnerable PHP 8.1.0-dev server

No authentication.

No brute force.

No login.

No prior access.

Impact

Successful exploitation allows attackers to:

• Execute arbitrary operating system commands
• Execute arbitrary PHP code
• Read sensitive files
• Modify web applications
• Upload web shells
• Install persistent backdoors
• Dump databases
• Steal credentials
• Escalate privileges
• Pivot deeper into internal networks
• Completely compromise the affected host

In practice, this vulnerability results in full server compromise.

MITRE ATT&CK Mapping

Detection

Administrators should immediately investigate systems that expose:

PHP/8.1.0-dev

within response headers such as:

X-Powered-By:

PHP/8.1.0-dev

HTTP logs should also be examined for suspicious requests containing:

User-Agentt

or

zerodium

Many intrusion detection systems and IPS products now include signatures specifically for this attack pattern. :contentReference[oaicite:2]{index=2}

Indicators of Compromise (IOCs)

Possible indicators include:

• Requests containing User-Agentt
• Header values beginning with zerodium
• Unexpected command execution
• Unknown PHP files
• New web shells
• Suspicious child processes spawned by PHP
• Unexplained outbound network connections

Exploitation Complexity

This is considered one of the easiest Remote Code Execution vulnerabilities to exploit because the attacker simply sends a crafted HTTP request.

Mitigation

Never deploy development snapshots of PHP on production systems.

If a server was found running the compromised build:

1. Remove the vulnerable version immediately.
2. Upgrade to a stable PHP release.
3. Assume full compromise.
4. Rotate all credentials.
5. Audit for web shells.
6. Review authentication logs.
7. Inspect scheduled tasks and persistence mechanisms.
8. Rebuild the server if compromise cannot be ruled out.

Security Lessons

This incident demonstrated several important lessons:

• Development builds should never be exposed publicly.
• Software supply chains are high-value attack targets.
• Code signing and infrastructure security are critical.
• Source code repositories require continuous monitoring.
• Small code changes can hide catastrophic vulnerabilities.
• Trust in upstream software must always be verified.

The compromise accelerated changes to PHP's development infrastructure and highlighted the growing importance of software supply chain security across the industry. :contentReference[oaicite:3]{index=3}

References

• PHP Internals discussion regarding the malicious commits
• PHP source repository incident reports
• Packet Storm Security exploit release
• Juniper Threat Labs IPS signature
• Community technical analyses
• Public exploit research

Conclusion

The PHP 8.1.0-dev User-Agentt Backdoor remains one of the most significant examples of a software supply chain attack affecting a major open-source project. Rather than exploiting a programming flaw, attackers inserted a hidden backdoor directly into the language's source code, allowing unauthenticated remote execution of arbitrary PHP code through a specially crafted User-Agentt HTTP header. Although the compromised development snapshots were quickly removed and no stable PHP releases were affected, the incident underscored the critical importance of securing software development infrastructure, verifying code provenance, and avoiding the deployment of development builds in production environments. Today, the vulnerability is widely studied as a landmark case in supply chain security and serves as a reminder that the integrity of the software build process is just as important as the security of the code itself.