Last weekend, the PHP project disclosed that attackers had compromised its official Git server at git.php.net, pushing two malicious commits to the php-src repository under the names of Rasmus Lerdorf and Nikita Popov. The commits were disguised as typo fixes but contained a backdoor that would allow remote code execution on any server running the tainted builds. The PHP team caught it quickly, but the implications ripple far beyond one project.
What Actually Happened#
On March 28th, two commits appeared in the php-src repository that looked innocuous at first glance — they were titled as minor typographical corrections. But buried in the code was a line that checked for a specific string in the HTTP User-Agent header and, if matched, executed arbitrary PHP code. It was a textbook webshell hidden in plain sight.
The PHP maintainers reverted the commits within hours and began investigating. The working theory is that the git.php.net server itself was compromised, rather than individual developer accounts. This is a critical distinction: it means the attacker bypassed the authentication layer at the infrastructure level.
As a result, the PHP project has made the decision to move its canonical repository to GitHub. The self-hosted git.php.net server, which has served the project for years, is being retired. It’s a pragmatic choice, but also a symbolic one — the era of major open-source projects self-hosting their critical infrastructure is fading.
The Supply Chain Trust Problem#
This incident crystallizes a problem that’s been growing for years: the software supply chain is only as strong as its weakest link. PHP powers roughly 79% of websites with a known server-side language, according to W3Techs. If those malicious commits had made it into a release — even a minor one — the blast radius would have been staggering.
We’ve seen variations of this before. The event-stream incident in the Node.js ecosystem in 2018 showed how a single compromised package could affect thousands of downstream projects. The SolarWinds breach demonstrated nation-state-level supply chain attacks. But there’s something particularly unsettling about an attacker gaining commit access to a language’s source code itself.
The trust model in open-source has traditionally been built on reputation and review. Maintainers know each other, they review each other’s code, and the commit history is public. But when the server hosting that commit history is compromised, all of those safeguards evaporate. You can’t trust a code review process if the attacker can modify the code after review.
Self-Hosting vs. Platform Dependency#
The PHP team’s move to GitHub is practical — GitHub has dedicated security teams, hardware security modules for signing, and infrastructure that most open-source projects can’t match. But it does raise questions about centralization. We’re putting an enormous amount of trust in a single platform (owned by Microsoft) to host the source code for the majority of the open-source ecosystem.
I’ve run self-hosted Git servers for client projects over the years, and the maintenance burden is real. Keeping the server patched, managing SSH keys, monitoring for intrusions — it’s a full-time job that most open-source projects don’t have the resources for. The PHP project maintained git.php.net with a small team of volunteers, and that was apparently enough for attackers to find a way in.
The trade-off is clear: self-hosting gives you control but demands constant vigilance. Platform hosting gives you security infrastructure but creates a dependency. For most projects, the answer is increasingly obvious — let the platform handle infrastructure security while you focus on code quality.
Commit Signing Matters More Than Ever#
One of the key takeaways here is the importance of cryptographic commit signing. If the PHP project had enforced GPG-signed commits, the malicious pushes would have been immediately flagged — the attacker would have needed not just server access but also the private keys of the developers they were impersonating.
Git supports commit signing natively, and GitHub can verify signatures and display a “Verified” badge. Yet adoption remains surprisingly low, even among major projects. It’s one of those security practices that everyone agrees is important but few actually implement consistently.
If you maintain an open-source project — or even a private one — now is the time to enforce signed commits. The tooling has gotten significantly better, and the cost of not doing it was just demonstrated in vivid detail.
My Take#
I’ve been working with PHP since the PHP 3 days, and while I’ve moved on to other languages for most of my work, I still have a deep respect for the ecosystem. The speed of the response here was impressive — the maintainers caught the malicious commits within hours, not days or weeks. That’s the open-source model working as intended.
But this incident should be a wake-up call for every open-source project that self-hosts critical infrastructure. The attack surface is expanding, and volunteer maintainers are increasingly outmatched by well-resourced adversaries. Moving to platforms with professional security teams isn’t a sign of weakness — it’s an acknowledgment of reality.
The broader question of software supply chain security isn’t going away. If anything, attacks like this one, combined with SolarWinds and the growing catalog of compromised packages, suggest we need fundamental changes in how we verify and distribute software. Signed commits, reproducible builds, and transparent build pipelines aren’t optional anymore. They’re the minimum bar for a trustworthy software ecosystem.