Tabla de contenidos

php2shell: When 40% of the Internet was at risk

The handling of the php2shell vulnerabilities has shaken the global cybersecurity landscape.

This incident not only exposed more than 70% of the world’s websites to an imminent risk of Remote Code Execution (RCE), but also highlighted the fragility of ageing digital infrastructure and the breakdown of the traditional process for disclosing critical security vulnerabilities.

The Root of the Problem: Ageing Infrastructure

The infrastructure supporting the Internet has been in place for decades. Just because a system like PHP has been running reliably for years does not necessarily mean it is secure.

Maintaining compatibility with legacy applications, libraries and extensions makes fixing vulnerabilities a slow and complex process. Changing a single line of old code can potentially disrupt thousands of applications that depend on it.

In fact, the PHP Foundation had already identified one of the flaws behind this crisis during a routine review in 2024. However, no known method of exploitation had been discovered at the time, and the fix was postponed due to its complexity.

What nobody anticipated was how dramatically the emergence of frontier AI models would accelerate this process, turning dormant vulnerabilities into critical security threats within hours.

Timeline of a Crisis Waiting to Happen

Coordinated vulnerability disclosure exists for a fundamental reason: to give open-source software maintainers enough time to validate findings, develop fixes and distribute security patches before technical details become publicly available and potentially exploitable.

With php2shell, that process broke down.

  • October 20: A post on Hacker News revealed the upcoming disclosure of vulnerabilities CVE-2026-109618 and CVE-2026-109619, breaking the traditional disclosure embargo. Proof-of-concept (PoC) exploits quickly began circulating publicly before the PHP team could fully assess the impact or prepare fixes.
  • October 20 (12:30 UTC): Just hours after the leak, Amazon Threat Intelligence detected the first automated exploitation attempts through its MadPot telemetry.
  • October 20 (15:00 UTC): Facing unprecedented pressure, the PHP Foundation issued an extraordinary advance notice announcing emergency security updates.
  • October 21: Patched PHP versions were rapidly released: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The Role of AI and OpenAI: Solution or Part of the Problem?

Artificial intelligence has proven to be a double-edged sword.

On the one hand, companies such as Google Cloud and cybersecurity firms use AI models to analyse large volumes of code, identify complex memory-related vulnerabilities and even generate security patches.

On the other hand, these same capabilities have drastically reduced the time available for human intervention.

OpenAI stated that its Patch the Planet initiative helped uncover vulnerabilities that had remained hidden in PHP’s codebase for a decade.

However, on October 21, at the height of the crisis, while system administrators were working to contain ongoing attacks, OpenAI published a proposal for a new framework to coordinate the disclosure of critical vulnerabilities.

The announcement sparked strong criticism within the technical community. Introducing a new self-regulatory framework after the existing coordinated disclosure process had broken down, without having prevented the embargo leak, raised serious questions about the credibility of vulnerability disclosure models promoted by the AI industry.

The Human Bottleneck in the Age of AI

The growing number of critical vulnerabilities reported in recent weeks, alongside incidents such as Linux PwnEscape and 10/10-severity RCE vulnerabilities in GitLab, highlights a deeper structural problem: AI can identify vulnerabilities at unprecedented speed, but responding to and fixing them still depends on limited human resources.

Updating systems in large organisations is not as simple as clicking a button. It often involves migrating outdated dependencies, auditing legacy code and ensuring that security fixes do not disrupt essential services.

When AI-powered vulnerability discovery outpaces IT teams’ ability to deploy patches, technical debt stops being merely a performance or maintenance issue and becomes a direct threat to business continuity.

FAQ

Why does AI increase security risks in legacy software?

AI enables security researchers and cybercriminals to analyse millions of lines of code in minutes, identifying potential attack vectors and memory management vulnerabilities that might previously have taken years to uncover.

Why was breaking the disclosure embargo so serious in this case?

Because it left more than 1.3 million servers potentially exposed before PHP maintainers had released the necessary security patches.

What should organisations do to address this new reality?

Reduce technical debt, migrate away from end-of-life (EOL) software versions and recognise that the window between vulnerability discovery and active exploitation has become increasingly narrow, in some cases shrinking to almost zero.