On March 28, 2021, two commits landed in the php-src repository that should never have existed. They were attributed to Rasmus Lerdorf, the creator of PHP, and Nikita Popov, one of its most prolific core maintainers — two of the most trusted names in the language's history. Neither had written them. The commits carried an innocuous message, "fix typo," but buried inside was a fully functional remote code execution backdoor. This was not a phishing email or a leaked password. It was a PHP git server compromise: attackers had breached the infrastructure behind git.php.net itself and used it to push malicious code under the identity of maintainers who had no idea it was happening. The incident became one of the starkest warnings the open-source world has received about what happens when trust in a git server substitutes for verification of the humans behind it.
What Was the PHP Git Server Compromise of 2021?
The PHP git server compromise was an attack in which unknown actors gained unauthorized access to the self-hosted git server at git.php.net and pushed two malicious commits directly to the php-src repository, PHP's primary source tree, on March 28, 2021. The commits were timestamped and authored to look like they came from Rasmus Lerdorf and Nikita Popov. Because git.php.net was the canonical, self-hosted source of truth for the PHP language at the time — predating PHP's later move to GitHub as the system of record — a push that made it past the server's authentication carried enormous weight. Anyone mirroring or pulling from git.php.net, including downstream package builders and distribution maintainers, would have inherited the backdoored code without any obvious red flag beyond the commit history itself.
What made this especially alarming for the broader software supply chain is that PHP powers a huge share of the web — WordPress, Drupal, Magento, and countless custom applications all depend on the PHP runtime. A backdoor injected quietly into the interpreter itself, rather than into a single application, would have had a blast radius touching millions of production servers.
How Did the Backdoor Actually Work?
The backdoor worked by hiding malicious logic inside a function related to PHP's user-agent parsing, triggered by a specifically malformed HTTP header. The injected code checked incoming requests for a header named "User-Agentt" — deliberately misspelled with an extra "t" so it wouldn't collide with normal traffic or be noticed casually — and if present, passed its contents to zend_eval_string(), PHP's internal mechanism for evaluating a string as executable PHP code. In effect, any server running a PHP build compiled from this tainted source would have granted remote code execution to anyone who knew to send that one crafted header. There was no authentication check, no obfuscation beyond the misspelled header and the disguise of a "typo fix" — this was a source code backdoor built for simplicity and stealth rather than sophistication, designed to blend into a routine-looking diff.
How Was the Maintainer Impersonation Discovered So Quickly?
The maintainer impersonation was caught within hours because PHP core developers reviewing the php-internals mailing list and commit history noticed the changes didn't match how Lerdorf or Popov actually write code, and both denied authoring them once alerted. Nikita Popov publicly stated he had not made the commits attributed to him and that the git.php.net server, not his personal account or credentials, appeared to be the point of compromise. The commits were reverted almost immediately, and no evidence emerged that the backdoored code was ever shipped in an official PHP release or reached end users through the normal release process. The speed of detection came down to community vigilance rather than any automated safeguard — engineers who knew the codebase and the people behind it well enough to recognize an impostor's diff at a glance.
Why Did PHP Decide the Git Server Itself Was Compromised?
PHP's maintainers concluded the git server itself was compromised, rather than individual developer credentials, because forensic review pointed to unauthorized access at the infrastructure level of git.php.net rather than to phished or stolen personal accounts belonging to Lerdorf or Popov. The team was unable to fully pin down the precise initial entry vector, but the working theory centered on a compromised user database on the master.php.net server used for authentication, potentially exposing password hashes that could have been leveraged to forge commits under legitimate maintainer identities. This distinction mattered enormously: a compromised individual account is a bounded incident affecting one person's access, but a compromised git server is a systemic failure that can be used to impersonate any maintainer, at any time, without their knowledge. It reframed the incident from "someone's account got hacked" to "the infrastructure everyone trusted was no longer trustworthy."
What Changed After the Incident?
The most consequential change was that PHP abandoned self-hosted git infrastructure as its source of truth and moved php-src, along with its other repositories, to GitHub. The PHP project announced that going forward, changes would need to go through GitHub's pull request and authentication model rather than direct pushes to git.php.net, which was demoted to a read-only mirror. This was a significant cultural shift for a project that had run its own git infrastructure for years, but the calculus was straightforward: GitHub's authentication, audit logging, two-factor enforcement, and commit-signing tooling offered stronger guarantees against a repeat of March 2021 than a smaller team could realistically maintain on its own self-hosted git server. The incident became a widely cited case study in why "we host our own infrastructure" is not automatically more secure than relying on a hardened, well-resourced third-party platform with mature access controls.
Could This Kind of Attack Happen Again?
Yes — the underlying conditions that enabled the PHP git server compromise still exist wherever a single git server, credential store, or CI system sits between a maintainer's identity and the code that ships to production. Git commits are trivially easy to forge in terms of author name and email; nothing about the commit format itself proves that Rasmus Lerdorf typed the code attributed to him. What actually protects a project is the strength of the infrastructure guarding push access, the presence of commit signing tied to hardware-backed keys, and independent verification of unusual changes before they merge. Self-hosted developer infrastructure — git servers, package registries, build systems — remains an attractive target precisely because compromising it once can yield ongoing, low-friction access to inject a source code backdoor into a project trusted by millions of downstream consumers, all while wearing the identity of a maintainer nobody would think to question.
How Safeguard Helps
The PHP incident is a clean illustration of a problem Safeguard is built to address: an attacker who can push to your git infrastructure doesn't need to steal a maintainer's laptop — they just need the server to say yes. Safeguard continuously monitors source code repositories and CI/CD systems for anomalous push activity, unexpected commit authorship patterns, and changes that don't match a contributor's established behavior, flagging maintainer impersonation attempts before they reach a build or release pipeline. Rather than relying solely on manual code review to catch a disguised "fix typo" commit, Safeguard's supply chain monitoring correlates commit metadata, authentication events, and infrastructure access logs to surface the kind of infrastructure-level compromise that let two forged commits slip past git.php.net in 2021.
Safeguard also helps teams harden the exact weak point this incident exposed: the gap between "this commit says it's from a trusted maintainer" and "this commit actually came from that maintainer." By enforcing and verifying commit signing, tracking git server and credential-store access patterns, and alerting on privilege or infrastructure changes that deviate from baseline, Safeguard reduces the odds that a single compromised server can be used to quietly rewrite the trust model an entire open-source ecosystem depends on. For organizations that depend on PHP, or on any language runtime and its upstream supply chain, that kind of continuous verification is the difference between catching a backdoor in hours, the way the PHP community did, and shipping it to millions of servers before anyone notices.