The World Wide Web's "Front Door" Has Been Breached…The Full Story Behind the PHP2Shell Uproar

A critical security vulnerability that had been hidden for over a decade in PHP, a programming language used by approximately 7 out of every 10 websites on the internet, has been discovered. Until a patch was released on the 21st, the incident—marked by leaks and mistakes intertwining—came to be known in the security industry as the "PHP2Shell uproar." We've traced this event in chronological order.

First, the nature of the vulnerability. PHP is a language that forms the foundation of the web, from homepage creation tools like WordPress to shopping malls and message boards. The two vulnerabilities in question (CVE-2026-109618·109619) breach the PHP engine itself. Without logging into a homepage, and regardless of whether a site's code is poorly written, external parties can now remotely control the server. To use a home analogy, it's as if the front door itself opens entirely, not just the door lock. The scope of impact spans essentially all versions released over the past ten years—from PHP 5.4 through 8.5—with a severity rating of 9.2 out of 10 (some security firms rate it a perfect 10).

2024. This bug was spotted once internally by the PHP development team. However, it was dismissed as a simple memory error and left unpatched, buried in obscurity. This is why the vulnerability survived as "ten years old."

August this year. Security startup Califf and cloud security company Wiz independently discovered the same vulnerability through AI-powered code analysis. This is why the security industry calls this incident "the first major vulnerability discovered by AI." Following convention, both companies reported it confidentially to the PHP development team, and a "coordinated disclosure" process began in which they maintained secrecy until a patch could be prepared.

October 17. Four days before the planned disclosure date, actual attack attempts targeting this vulnerability were detected in Amazon Web Services' (AWS) monitoring network. It was a signal that the secret had already leaked.

October 20. This was the day the coordination unraveled in layers. Vulnerability information leaked to overseas communities, and the discovering company accidentally uploaded then deleted attack demonstration videos. A security firm breached the embargo and distributed the fix early; attackers then reverse-engineered the patch contents and created and distributed attack code before the public patch release. The PHP development team issued an urgent advance notice, and the Wikimedia Foundation preemptively took some systems offline as a precaution.

October 21. The PHP development team released the patch ahead of schedule. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. For legacy versions no longer supported (7.4–8.1), only source code fixes were provided without an official patch. Around this date, security firms demonstrated remote takeover on major site configurations like WordPress, and multiple firms including AWS and Cloudflare observed actual attack attempts.

October 22. South Korea's response began in earnest. The Korea Internet & Security Agency (KISA) released response guidelines through Boho-nara, and major hosting firms including Cafe24 and Gabia announced completion of server patches. AhnLab tallied approximately 110,000 vulnerable PHP assets exposed to the internet domestically (estimated before patching)—the sixth largest in the world. As of that day, no domestic damage cases had been confirmed.

So how dangerous is the situation now? It's not a "master key" that opens everything with a single click; multiple conditions must be combined, so it's not a situation where the entire global web collapses immediately. However, there's no clear workaround, so patch application is the only solution. There's essentially nothing an ordinary user can do right away. It's a problem with web server infrastructure, not personal PCs or smartphones. The ball is in the hands of site operators. Small shopping malls or hobby community homepages with sparse management are the most likely to remain at risk the longest.

The security industry sees this incident as a watershed moment following Heartbleed in 2014 and Log4Shell in 2021. AI found a ten-year-old hole, but the human disclosure procedures creaked at multiple points. As AI's speed in finding vulnerabilities accelerates, the social procedures for managing them remain unchanged. That is the real challenge the PHP2Shell uproar has left behind.