On the afternoon of Tuesday, 20 October, an anonymous post appeared on Hacker News. It claimed that two remote code execution flaws in PHP were about to be disclosed. The post was deleted within hours, but screenshots had already travelled across X and Mastodon. By evening, the security firm watchTowr had confirmed the bugs were real, and the PHP security team had put out an unusual advance notice: a critical security release was coming the next day, and everyone should get ready.

By Wednesday, the internet was in triage. Government portals in Europe went dark by choice. Companies including Nintendo and BambooHR pulled services offline as a precaution. The US National Security Agency told organisations to patch immediately or disconnect. India's CERT-In issued its own advisory flagging a high risk of complete system compromise. And the researchers who found the flaws said openly that they had used frontier AI models to do it.

The pair of vulnerabilities, now known as PHP2Shell, is a security story. It is also something bigger: the clearest demonstration yet that AI has changed the economics of finding and exploiting software flaws. For an industry that has spent two decades assuming that old, heavily reviewed code is safe code, that is an uncomfortable lesson.

First, a correction: PHP was not "hacked"

Much of the early coverage, and a lot of the panicked forwarding on WhatsApp, framed this as "PHP has been hacked". That is not quite right, and the difference matters for how you respond.

PHP is a programming language and runtime. It is the engine that sits on a web server and builds pages for WordPress, Drupal, Joomla, Magento, WooCommerce, MediaWiki and a very long tail of custom business applications. Nobody broke into PHP. What happened is that researchers discovered two serious weaknesses in the engine itself, and those weaknesses can be used to break into any server running a vulnerable version.

So the question for a business is not "was PHP hacked?" It is "is my server running a vulnerable PHP version, and has anyone already used that window to get in?" Those are two separate jobs: patching, and checking.

What PHP2Shell actually does

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. PHP rates both 9.2 out of 10 on the CVSS v4.0 scale. watchTowr went further and scored it a full 10. Either way, this is the top tier of severity.

In plain terms, an attacker sends a specially crafted web request to your site. No login, no password, no stolen credentials. That request pushes PHP into running out of memory at exactly the wrong moment, leaving behind broken internal data. A later request, often handled by the same server worker, then trusts that broken data. The result is that the attacker's own code runs on your server.

PHP's own advisory describes the two mechanisms precisely. The first, CVE-2026-109618, involves out-of-memory handling interrupting PHP while internal request data is only partly set up, so that cleanup later treats invalid data as valid. The second, CVE-2026-109619, involves request-owned internal state surviving after its memory has been freed, so that a later request can use that stale state before it is reset. Security firm Sansec notes that the vulnerable code traces back to PHP 5.4.0, released in 2012, and that default configurations are affected.

Three details make this unusually dangerous:

• It sits in PHP itself, not in a plugin or theme. Wiz says even a bare "Hello World" application on an affected version can be vulnerable, and it demonstrated unauthenticated takeover of the latest container images of WordPress, Drupal and Joomla.
• The attack fires before your application code runs. A perfectly maintained, fully updated WordPress site is still exposed if the PHP underneath it is old.
• It can leak memory as well as run code. Wiz has warned that leaked process memory may contain passwords, tokens and API keys, which means the damage can outlive the patch.

Once an attacker has code running on the server, the menu is familiar and grim: read the database, copy customer records, harvest the credentials stored in configuration files, plant a backdoor, deface or redirect the site, or quietly use it to serve malware to every visitor who trusts your brand.

PHP's advisory says every installation serving web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk on mod_php.

Who found it, and how AI changed the maths

Two teams found the flaws independently over the summer.

The first was Calif, a California-based AI red-teaming firm led by Thai Duong, one of the researchers behind the 2014 POODLE attack on SSL. According to The Wall Street Journal, as reported by Quartz, Calif researcher Ryan Austin was running an OpenAI-funded audit of PHP's source code in August, using OpenAI's cybersecurity-focused model GPT-5.6 Sol. Fortune reports that the Calif team picked PHP because it was a high-impact target, and did not expect to find anything critical, given how heavily the language has been scrutinised for years. Calif reported the first bug to PHP on 11 August and the second on 21 August.

The second was Wiz, the cloud security company Google acquired earlier this year. Its researchers Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz identified the issues on 19 August and reported them to PHP on 24 August, working with GPT-5.6 Sol, Google's Gemini 4 Argon and Wiz's own Atlas AI tool.

What is striking is not just the discovery. Finding a memory bug is one thing. Turning it into a reliable exploit that works across different PHP versions, configurations and application behaviours has historically been the hard part, the slow, expensive work of a small number of elite specialists. Wiz has said that this is no longer a barrier. Its researchers wrote that, with frontier models and the right tooling, a single researcher completed in a week what would previously have taken a world-class team months.

That is the real headline. Wiz framed it as a shift in the economics of both discovery and exploitation: when AI cuts the effort needed to build and adapt complex exploits, bugs that once seemed too fiddly to weaponise become practical targets. Its researchers compared PHP2Shell to Heartbleed as a possible turning point, and summed it up in one line: "It marks an AI inflection point."

Think about what that means for the rest of the software stack. PHP is not obscure code. It is among the most reviewed open-source projects on earth. If a decade-old, critical, unauthenticated flaw was still sitting in its core, and AI could surface it in weeks, the same is almost certainly true of other foundational software that nobody has yet pointed these tools at.

The disclosure that broke early

The plan was orderly. Linux distributions and long-term support vendors received patches in advance. Public disclosure and fixed releases were scheduled for Thursday, 22 October. Then the embargo collapsed.

Alongside the Hacker News post, a screenshot of an exploit tool called PHP2Shell, credited to Calif, leaked, and a short exploitation video appeared briefly before being taken down. Analysts also report that Chainguard published patched container images hours before the official release. PHP pulled its release forward by a day and shipped the fixes on Wednesday, 21 October, at around 14:00 UTC.

The 17 October entry deserves a second look. Amazon's chief security officer CJ Moses has said its honeypots caught a PHP2Shell attempt four days before anything was public, and that the bug was being broadly exploited in the wild. Security firm Hadrian has said it observed exploitation at scale. CISA and several national agencies had not confirmed exploitation when they published their alerts, so the picture is still forming. But the safe working assumption for any business is simple: someone may have been knocking on your door before you knew there was a door.

When governments switch off their own websites

Governments rarely take their own websites down on purpose. On Wednesday, several did.

The NSA issued a rare public advisory telling organisations to update immediately or take systems offline until they could, warning that the flaws often provide a direct path to a server's files or database. CERT-EU and the UK's National Cyber Security Centre gave similar advice. CISA recommended patching. Korea's KISA, Japan's authorities and Australia's Signals Directorate all issued alerts, and Japan's Prime Minister Sanae Takaichi personally warned the public on social media.

Then the switches started flipping. Germany's digital ministry took some sites offline as a precaution. France's interior ministry disconnected websites serving local administrative offices. In the Netherlands and Finland, government sites went dark, with Finland's state IT provider Valtori describing it as a precautionary step rather than a response to any breach. In Denmark, services including a national school communication platform were affected. In Australia, ABC News reported that GovCMS blocked direct access to servers behind major government sites, Moodle took its site offline and hosting provider VentraIP restricted file uploads for customers. The Record counted hundreds of sites down across the day.

There is a lesson in that caution. These are organisations with security teams, budgets and established patch processes, and they still decided that a few hours offline was cheaper than the risk of a few hours exposed. For a small business on shared hosting, with no security team at all, that calculation should be sobering.

Why India should be paying close attention

India is one of the world's largest PHP economies. A huge share of the country's small and mid-sized business websites, e-commerce storefronts, education portals, hospital and clinic sites, NGO pages and state government services run on PHP stacks, often on affordable shared hosting, often maintained by a freelance developer who built the site years ago and has not logged in since. That is precisely the profile PHP2Shell punishes.

CERT-In moved quickly. Its advisory, addressed to all organisations and individuals using PHP, flagged a high risk of remote code execution and complete system compromise, and urged patching or isolating affected systems. Inc42 reported that DownDetector showed service issues on several high-traffic Indian platforms, including telecom, banking and railway booking sites, during the same window; no link between those issues and PHP2Shell has been confirmed, and readers should treat that as context rather than cause.

Three Indian realities raise the stakes:

• Legacy versions are everywhere. Older PHP releases, including PHP 7.x and early 8.x, remain common on Indian shared hosting because upgrading can break old themes and custom code. PHP 8.1 and older no longer get official releases from the PHP project, so these sites depend on a hosting company or distribution backporting the fix, or on an upgrade.
• Reporting obligations are real. Under CERT-In's 2022 directions, service providers, intermediaries, data centres and body corporates must report specified cyber incidents within six hours of noticing them. A compromised server holding customer data is not a problem you can quietly fix on Monday.
• Data protection exposure is rising. As the Digital Personal Data Protection framework phases in, a breach of personal data stops being only an IT embarrassment and becomes a compliance and liability event, with notification duties to affected people and the Data Protection Board.

For India's digital public infrastructure ambitions, PHP2Shell is also a reminder that the front door of many citizen services is still a PHP web form. Resilience is not only about the core platforms. It is also about the thousands of departmental and municipal sites that sit around them.

The uncomfortable symmetry: AI on both sides

Defenders found PHP2Shell with AI. That is the good news. The bad news is that nothing about those tools is exclusive to defenders.

Sansec predicted that mass exploitation would begin within 15 minutes of the patch being released. Calif's Thai Duong told The Wall Street Journal, as reported by Quartz, that someone could simply run AI against the patches and post an exploit script. That is the new pattern to understand. A security patch is, among other things, a precise map of where the weakness was. In the past, reverse-engineering a patch into a working attack took skilled people days or weeks. With capable AI models, that window is collapsing towards hours.

This changes the meaning of "we will patch in the next maintenance cycle". For critical, unauthenticated flaws in widely used infrastructure, the gap between disclosure and attack is now too short for monthly or even weekly patch routines. It also means the fixes themselves will be probed. Attackers will look for edge cases the patch did not cover, configurations where mitigations fail, and the many servers where the patch was assumed to be applied but was not.

There is a defensive upside. The same economics that make exploitation cheaper also make auditing cheaper. Initiatives to point AI at critical open-source code before attackers do are now clearly worth funding, and PHP2Shell is a strong argument for companies that depend on open source to put money and engineering time behind that effort rather than treating it as someone else's job.

What to do now: a practical checklist

If your organisation has a website, a customer portal, a booking form or an internal tool that runs on PHP, here is the sequence to follow. It applies whether you run your own servers or rely entirely on a hosting company.

1. Find out which PHP version you are on, today. Ask your hosting provider or IT team directly. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Anything earlier in those branches is vulnerable.
2. Do not assume WordPress updates have covered you. Automatic WordPress, plugin and theme updates do not update PHP, which is part of the server. This fix has to come from whoever manages the server.
3. If you are on PHP 8.1 or older, treat it as urgent. The PHP project no longer ships official releases for these versions. The PHP security team has published minimal source backports for 7.4, 8.0 and 8.1, and some Linux distributions and support vendors offer backported fixes, but the durable answer is to upgrade to a supported version. Note that PHP 8.2 reaches end of life on 31 December 2026.
4. If you cannot patch immediately, reduce exposure or go offline. Follow the NSA, CERT-EU and NCSC guidance: isolate or take the system offline until it is fixed. A web application firewall from providers such as Cloudflare can block known attack patterns, but it buys time; it does not fix PHP. PHP's advisory lists interim settings, such as disabling session upload progress and tightening request size limits, that reduce specific attack paths without making a server safe.
5. Check your logs back to 17 October. Amazon has advised reviewing server logs from that date, not just from the disclosure. Look for unusual requests, new files in web directories, unexpected admin users and outbound connections you cannot explain.
6. Rotate secrets after patching. Because the flaws can leak memory, change the database passwords, API keys, payment gateway credentials and tokens that live on the affected server once it is patched. Rotating before patching achieves little.
7. Know your reporting duties. If you find signs of compromise, Indian organisations covered by CERT-In's directions must report within six hours. Have your contact and incident details ready before you need them.

The boardroom question PHP2Shell raises

For business leaders, the technical details will fade. The strategic lesson should not.

For years, many companies treated their website as a marketing asset and their PHP version as an invisible detail owned by a vendor. PHP2Shell shows that this detail can decide whether customer data stays private, whether a regulator gets involved, and whether a brand ends up serving malware to its own customers. Three questions now belong on the management agenda, not just the IT ticket queue:

• Do we know every internet-facing system we run, which software it depends on, and who is accountable for patching it? Shadow websites, old campaign microsites and forgotten subdomains are where incidents like this land hardest.
• Are our patch timelines built for an AI-speed threat? For critical, unauthenticated flaws, the realistic target is now hours, not weeks, and contracts with hosting and agency partners should say so.
• Are we running software past its end of life? Unsupported versions are no longer a technical debt line item. They are an open liability, because when the next PHP2Shell arrives, there may be no official fix for them at all.

There is also a wider industry point. AI models capable of finding and weaponising this class of bug now exist and are improving. Responsible disclosure processes, built for a world where exploitation took weeks, are under strain, as the leak-and-scramble of the past 48 hours made plain. Expect regulators, national CERTs and the open-source community to revisit embargo timelines, patch distribution and the funding of security audits for critical shared infrastructure.

PHP2Shell is not the end of the web, and the fix is available. Most organisations that act this week, by confirming their PHP version, patching or isolating, checking their logs and rotating their secrets, will come through it fine. The ones at risk are those who assume someone else has handled it.

The bigger story will last longer than this patch cycle. AI has just shown that it can find critical flaws in some of the most trusted code on the internet, and turn them into working attacks, faster than the industry's habits were designed for. The same capability is available to defenders and attackers alike. The organisations that come out ahead will be the ones that treat speed of response, visibility of their own systems and retirement of unsupported software as business priorities, not technical chores.

AI Spectrum India will continue to track PHP2Shell, the follow-on advisories and what it means for Indian enterprises and public infrastructure. Understanding AI, on both sides of the security line, is now a business advantage, not an option.