Meet Ondřej Surý, the Man Who Helped Save the Internet From PHPocalypse

Startup News 1 week ago

startup #code

Meet Ondřej Surý, the Man Who Helped Save the Internet From PHPocalypse

As two critical PHP vulnerabilities triggered a global security scramble, a Czech software engineer working in his spare time helped make emergency fixes easier to deploy across thousands of servers. His story exposes a troubling truth about the internet: some of its most important safeguards depend on people most users have never heard of.

On October 20, the internet came uncomfortably close to a cybersecurity crisis that could have affected millions of websites. Two critical vulnerabilities in PHP, the programming language that powers roughly 70 percent of websites, threatened to give attackers the ability to execute code on vulnerable servers without authentication.

The vulnerabilities were serious enough to trigger an emergency response from the PHP security team. But fixing the underlying software was only half the battle. Once the patches became available, administrators around the world needed a reliable, straightforward way to install them—preferably before attackers could exploit their systems.

One person who helped make that possible was Ondřej Surý, a Czech software engineer who maintains PHP packages as a volunteer.

Surý does not work for the PHP Foundation, the organization supporting the language's development. Nor is he the sole person responsible for securing PHP. Instead, his contribution occupies a less visible but essential part of the software supply chain: turning source-code fixes into installable packages that administrators can deploy quickly and consistently.

In an interview with The Atlantic, Surý described the response as a problem to solve rather than a reason to panic. His experience, preparation, and automation helped organizations move faster during a crisis that exposed just how much modern internet infrastructure depends on a relatively small group of maintainers.

A crisis measured in hours

The PHP security incident began with the discovery of two critical remote code execution vulnerabilities, later identified as CVE-2026-109618 and CVE-2026-109619.

Both vulnerabilities received a CVSS v4.0 score of 9.2 out of 10. Under certain conditions, an unauthenticated attacker could exploit the flaws to execute code on a vulnerable server. Depending on the system and the attacker's resulting privileges, the consequences could include data theft, website defacement, malware installation, or the deployment of compromised servers into criminal botnets.

The flaws were especially concerning because PHP is embedded throughout the web. It powers content management systems, e-commerce platforms, business applications, and countless custom websites. A vulnerability in the language itself can therefore affect many otherwise unrelated organizations simultaneously.

The PHP Foundation had been coordinating work on the vulnerabilities, but the disclosure timeline was disrupted when information about the forthcoming security release began circulating online on October 20. The project moved its planned release forward, giving distributors and administrators less time to prepare.

The next day, PHP released security updates for its supported branches: versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

The urgency was no longer theoretical. Cloudflare chief executive Matthew Prince reported that the company had observed thousands of exploitation attempts during the ten hours before public disclosure. That figure rose to tens of thousands within 45 minutes of the announcement, hundreds of thousands within two hours, and eventually millions.

These figures represent reported attempts, not confirmed successful compromises. Nevertheless, they illustrate how quickly attackers can begin testing a newly disclosed vulnerability.

Sources: PHP's official security advisory and Reuters' reporting on the exploitation surge.

The volunteer behind the packages

Surý's contribution is not primarily about discovering vulnerabilities or writing the original security fixes. It is about ensuring that fixes can reach the people who need them.

He maintains a widely used third-party repository that distributes PHP packages for Debian- and Ubuntu-based systems. Rather than forcing every administrator to obtain the source code, compile PHP, and manage the installation manually, package repositories allow users to install and update software through familiar operating-system tools.

That distinction becomes critical during an emergency.

A source-code patch may be ready, but organizations still need a practical route from the fix to their production servers. Distributors must prepare builds, validate them, and make them available. Administrators then need to deploy those builds across their environments, sometimes spanning hundreds or thousands of machines.

Surý's automation and advance preparation made that process considerably easier for users of the packages he maintains.

As he explained to The Atlantic, the PHP project had given him advance notice of the vulnerabilities, allowing him to prepare the packages before the public release. He had been doing this work for more than 20 years, and much of the process was automated.

His work did not mean the internet depended exclusively on him. PHP can be obtained from other sources, compiled directly from source, or distributed through other maintainers and vendors. But losing a convenient, widely used distribution channel during a time-sensitive emergency would have made remediation more difficult for many administrators.

That is the less glamorous side of cybersecurity: a fix is only as useful as the systems that can actually install it.

Why a single volunteer became a symbol of internet security

As news of the incident spread, developers on social media began highlighting Surý's role.

One software developer, Ian Landsman, described the situation in a post quoted by The Atlantic: “And if anything happens to this guy, that’s just it. Everyone is screwed.”

The statement was deliberately dramatic, but it captured a genuine concern. Modern digital infrastructure is built on layers of open-source software maintained by people whose names rarely appear in public discussions about internet security.

When a website loads, a payment is processed, or a user logs in, the work of countless developers is operating behind the scenes. Many of those components are maintained by small teams, individual volunteers, or organizations that have limited funding relative to the number of businesses relying on their software.

Surý's own professional position makes the contrast particularly striking. Alongside his volunteer work on PHP, he serves as director of domain-name-system engineering at the Internet Systems Consortium, a nonprofit organization responsible for important internet infrastructure software.

His PHP maintenance work is a separate responsibility, sustained in part through community donations.

The incident generated an unusually large wave of contributions to support his work. Surý told The Atlantic that the donations received over roughly a day amounted to about a year's worth of contributions under his previous experience.

The outpouring of support demonstrated how quickly the public can recognize the importance of an otherwise obscure contributor when a crisis makes that work visible.

It also raises an uncomfortable question: why should it take a near-disaster for critical maintenance work to receive this level of attention?

The vulnerabilities were years in the making

The PHP incident was not simply a story about an unexpected bug discovered at the last minute.

According to the PHP Foundation's retrospective, the underlying out-of-memory vulnerability had been identified as a potential concern in 2024. Researchers had theorized a possible exploitation path, but a concrete route to remote code execution had not been established at that point.

Fixing the problem proved difficult because changes to PHP's memory handling and error management risked breaking compatibility, introducing other problems, or requiring coordinated changes across third-party extensions.

The Foundation acknowledged that the work stalled and restarted over several months. It described the delay as a structural failure involving both the security team's decision-making process and insufficient resources.

In 2026, additional security research established the severity of the issue. Researchers working with Calif, OpenAI, Wiz, and other security organizations helped clarify the impact and identify further attack paths. OpenAI independently reported the same underlying root cause, according to the Foundation's account.

The resulting crisis therefore had two sides: the vulnerabilities needed technically sound fixes, and the software ecosystem needed a way to deliver those fixes at scale.

Surý helped address the second problem. The PHP security team, Foundation-funded developers, release managers, and other package maintainers were essential to the first.

The distinction matters. The episode was not a story of one person defeating hackers single-handedly. It was a story of a complex, distributed response in which a small number of experienced people had to work together under intense time pressure.

Source: The PHP Foundation's account of the security release and its aftermath.

AI is changing the speed of cybersecurity

Another important element of the PHP incident is how the vulnerabilities were discovered.

The PHP Foundation says security researchers used AI-assisted tools as part of a broader effort to audit and test the language. The organization reported that OpenAI independently identified the same underlying vulnerability and supplied further attack vectors. The broader research effort also involved other security companies and specialized tools.

AI-assisted security research can help identify subtle defects, explore potential attack paths, and validate reports more quickly than traditional methods alone. But discovery is only one stage of the process.

The Foundation emphasized that experienced developers still had to assess the reports, understand the underlying code, weigh compatibility risks, review proposed changes, and produce the fixes.

That is where the PHP incident becomes a warning about the future of cybersecurity.

If AI tools accelerate vulnerability discovery, defenders may face a growing number of serious reports that require expert attention. Attackers can also use automation to investigate newly disclosed flaws and test systems at scale. The time available to coordinate a response may shrink, even as the technical complexity of the work remains unchanged.

Surý acknowledged that defenders and attackers are both moving faster. In his view, the deeper problem is that organizations have repeatedly treated IT infrastructure as something that can be neglected until a crisis occurs.

The challenge is no longer simply finding vulnerabilities. It is ensuring that the people and institutions responsible for fixing them have enough time, expertise, funding, and operational support to keep pace.

The internet was never supposed to depend on a handful of people

The PHPocalypse narrative makes for a compelling headline, but it risks obscuring the broader lesson.

Surý was not the only person involved, and the vulnerabilities did not mean that 70 percent of websites were inevitably going to be compromised. PHP's extensive use made the potential impact enormous, but actual exposure depended on the deployment, the attack path, and whether a system was patched or otherwise protected.

The emergency also did not end when the official updates were released. Administrators still needed to identify vulnerable systems, install the fixes, and investigate suspicious activity. Organizations running unsupported PHP versions faced additional challenges, although Surý told The Atlantic that older versions can also be patched.

The real concern is the fragility of the maintenance system itself.

The PHP Foundation acknowledged that the ecosystem needs more experienced developers and sustained financial support. Its security work depends on a relatively small group of specialists, even though PHP underpins services used by businesses, governments, and ordinary people worldwide.

Surý has argued that the current model can amount to exploitation when companies profit from open-source software without adequately supporting the people who maintain it.

The problem extends far beyond PHP. Critical components of the digital world—including programming languages, cryptographic libraries, networking tools, and operating-system packages—often rely on maintainers who receive only a fraction of the resources available to the organizations that depend on them.

A volunteer can be extraordinarily effective. But a responsible security strategy cannot assume that the same volunteer will always be available.

A hero story—and a warning

It is tempting to conclude that the internet was saved by Ondřej Surý. The reality is more complicated, and perhaps more important.

The PHP Foundation and its security team coordinated the response. Researchers uncovered and validated the vulnerabilities. Developers worked on the fixes. Distributors prepared patched releases. Maintainers such as Surý made the updates easier to deploy. System administrators and hosting providers then had to carry those fixes into production.

Surý's contribution deserves recognition precisely because it reveals how these parts fit together. Cybersecurity is not only about brilliant researchers or sophisticated defensive products. It also depends on the practical, often repetitive work that makes a security fix available to the people who need it.

The lesson from PHPocalypse is not that the internet should hope its next crisis has a volunteer ready to respond. It is that the people maintaining critical open-source infrastructure need reliable support before the next emergency arrives.

For Surý, the incident appears to have reinforced a responsibility he has carried for decades. For the wider industry, it should serve as a reminder that software maintenance is not an optional extra or a charitable afterthought.

It is part of the security infrastructure on which the internet depends.

And the next time a critical vulnerability emerges, the world should not have to discover the name of the person holding everything together only after the crisis has begun.

Sources