PHP2Shell: How AI Turns a Stalled PHP Flaw Into a Global Emergency

At 7 p.m. in Canberra on October 21, 2026, Australia’s GovCMS platform, which hosts websites for Australian government agencies, cut its servers off from direct internet access. Over the following hours, the same decision spread around the world.

Finland’s state IT center shut public traffic to government web services. In the Netherlands, the national login service DigiD took its website offline, followed by the parliament’s site, hospitals and the Port of Rotterdam. France put its prefecture websites into maintenance. In Tokyo, Prime Minister Sanae Takaichi urged website operators to go offline if they could not patch quickly.

None of these organizations reported a breach. They were reacting to PHP2Shell, two critical flaws in PHP, the software that runs behind most of the world’s websites. The repair was due that afternoon, but attackers were already probing for the flaws. Amazon later traced the earliest known exploitation attempt to October 17, four days before any public warning. Cloudflare’s chief executive says attempts grew from thousands before the patch to millions by the next morning.

What PHP2Shell Is, in Plain Terms

To understand why governments reacted so drastically, it helps to know where PHP sits. Most people never see it, but they use it constantly. PHP is the software on a web server that runs a website’s code and assembles each page a browser receives. WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud and countless company intranets depend on it. If a website is a restaurant, PHP is the kitchen: visitors only ever see the finished plate.

PHP2Shell is the collective name for two flaws in that kitchen, tracked as CVE-2026-109618 and CVE-2026-109619. Both involve how PHP cleans up when a request fails. An attacker sends a specially built web request, typically disguised as a file upload, that pushes PHP into an error at exactly the wrong moment.

The first flaw concerns running out of memory. PHP can be interrupted while it is still setting up internal data for a request. Its cleanup routine then treats that half-built data as complete, and an attacker who shapes the data carefully can steer what the server does next.

The second flaw works like a kitchen station that is not wiped down between orders. A failed request can leave behind a reference to memory that has already been released. When the next request reaches the same PHP worker, it can pick up those leftovers before the normal reset happens.

The worst outcome is remote code execution: the attacker’s commands run on the server, with no password or account required. Researchers also showed a quieter outcome. In Wiz’s demonstrations, an attacker could read chunks of the server’s working memory, which may hold other visitors’ passwords, session tokens, API keys or certificates. JFrog’s analysis compares that leak to Heartbleed, the 2014 bug that exposed memory on encrypted web servers.

Two details make PHP2Shell unusually dangerous. The attack happens inside PHP itself, so it does not matter whether a site’s own code is well written; Wiz notes that even a basic “Hello World” page on an affected version could be exposed. And in the most direct variant, the attack fires while PHP is still reading the incoming request, before WordPress or any other application has started. A login screen, a security plugin or an application’s maintenance mode never gets a chance to intervene.

That is also why the fix sits with whoever runs the server. Updating WordPress, Drupal or a shop plugin does not repair PHP. The WordPress project’s notice makes clear that the repair belongs to PHP and the hosting environment, not to WordPress itself.

How Far the Problem Reaches

Because the flaws live in PHP rather than in any single application, the exposure follows PHP wherever it runs. On October 22, W3Techs measured PHP on 69.3% of websites whose server-side language it could identify. Wiz, Calif and Cloudflare say the flaws reach back to PHP 5.4, released in 2012, so almost every PHP version still in use is affected.

The same W3Techs data reveals the harder part of the problem. Among PHP websites, 26.9% still run PHP 7 and 7.7% run PHP 5. Every PHP 7 and PHP 5 branch is past its official end of life, and so are PHP 8.0 and 8.1. More than a third of PHP websites therefore run a version that receives no regular fixes from the PHP project.

Internet scans point the same way, although they count very different things. None of them proves that a particular server can be exploited, many servers hide their version, and some carry a vendor’s repair under an old version number. The figures below should not be added together:

The exact totals matter less than the pattern. In every count that breaks servers down by version, machines on unsupported PHP outnumber those on supported branches, in some counts by nearly three to one. VirusTotal also found only about 85,000 servers running the newest PHP releases available before the fix. Many of the rest depend on a vendor backport, a migration or isolation, and some will receive none of those.

Visible websites are also only part of the picture. PHP runs inside hosting control panels, network appliances, admin tools and internal business applications that never appear as a “PHP website.” The Dutch National Cyber Security Centre published an inventory of products that may contain PHP, which it is still expanding. Its entries are leads to investigate, not a list of confirmed vulnerable products.

The Timeline at a Glance

That exposure did not appear overnight. The danger built up over two years, then compressed into four days in October. The table gives the sequence in Coordinated Universal Time (UTC); the sections that follow tell the story behind each step.

2004 to 2024: A Weak Spot Nobody Could Prove

The story of PHP2Shell begins long before its name. According to the researchers’ own history of the bug class, security researcher Stefan Esser found the first remotely exploitable PHP flaw involving the memory limit in 2004. In 2020, a bug report described how unusually long variables could push PHP into out-of-memory conditions.

The direct ancestor appeared in 2024. That year, Germany’s Sovereign Tech Agency funded the first external security audit of PHP’s core in years, organized by OSTIF and carried out by Quarkslab. The published audit results list 27 findings, 17 of them with security implications. While fixing one of those issues, a developer working for the PHP Foundation noticed the first signs of the memory problem behind PHP2Shell.

Nobody could yet show how to exploit it remotely, and every proposed repair came at a cost. Some broke compatibility, some created new ways to crash servers, and some required changes to many third-party extensions. In its October 21 account, the PHP Foundation says the security team decided by consensus, lacked engineers and had no proof of a remote attack, so the work stalled and restarted for months. The Foundation now calls that delay “a structural failure.”

The weakness therefore stayed in PHP, theoretical and unpatched, until researchers proved that it was not theoretical at all.

August 2026: Researchers Turn Theory into Working Attacks

The breakthrough came from researchers using AI models as power tools. On July 30, 2026, security firm Calif joined Patch the Planet, an OpenAI initiative that offers AI tools and hands-on support for securing widely used open-source software. Its researcher Ryan Austin picked a target he already knew well and had a specific theory about where PHP might fail.

His timeline moves quickly from there. On August 1, he found a way to make PHP run out of memory at an exploitable moment. On August 11, Calif reported the bug to PHP, and OpenAI reported it the same day. A working proof of concept followed on August 14, PHP confirmed it on August 15, and Calif reported a second bug on August 21.

Wiz reached the same territory independently. Its researchers say they found their first PHP flaw on August 19, achieved code execution against Drupal the next day and against WordPress the day after, then reported to PHP on August 24. OpenAI’s security team reported further attack routes on September 18. From August 11, according to the Foundation, fixing the problem was PHP’s top security priority.

The demonstrations explain the urgency. Calif reports attacks without login against recent releases of WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and the hosting-billing platform WHMCS, under default configurations. Wiz achieved code execution against the then-latest official WordPress, Drupal and Joomla container images.

What AI Changed, and What It Did Not

Both teams credit AI with much of the speed. Calif says it used no special harness or restricted models: Austin asked a language model to help find ways past PHP’s memory limit, and AI agents traced allocation and shutdown code to locate the interruption points. OpenAI says Calif used its GPT-5.6 Sol model. Wiz names Gemini 4 Argon, GPT-5.6 Sol and its own Wiz Atlas, and says the models helped adapt exploits across PHP versions, configurations and memory layouts.

Wiz estimates that one researcher with these tools finished in a week what would previously have taken a top-tier team months. That is the researchers’ own estimate rather than an independent measurement. Their accounts also show the human part of the work: choosing the target, knowing PHP’s vulnerability history, forming the hypothesis and judging the results. Designing a safe repair that would not break millions of applications remained the job of PHP’s maintainers.

The broader lesson is uncomfortable for defenders. A flaw that had resisted exploitation for years became practical within two weeks once AI-assisted researchers focused on it. From that point, defenders had to assume that attackers with similar tools could get there as well.

For Technical Readers: How the Two Flaws Work

The first flaw, CVE-2026-109618, sits in PHP’s out-of-memory handling. PHP has used longjmp() to abort a request when an allocation fails. If that happens while request memory is reachable but not fully initialized, request shutdown can later read or branch on invalid data. The advisory lists multipart parsing behaviors that let attackers trigger memory exhaustion within apparently normal limits, including parts with unlimited headers and requests without a usable content length.

PHP validated remote code execution for this flaw against Apache with mod_php, where PHP runs inside the web server, using default limits. Apache runs PHP’s shutdown routine even when request startup fails, so the attack completes before any application code runs. PHP-FPM, the separate process manager behind most Nginx setups and many modern hosts, ends the worker when startup fails. The advisory says FPM is still susceptible according to source analysis, although no complete FPM exploit for this CVE has been demonstrated.

The repair removes longjmp() from out-of-memory handling. PHP now triggers a controlled “soft” failure at the next safe point and, if memory keeps growing, exits the process at a higher hard threshold.

The second flaw, CVE-2026-109619, needs two requests handled by the same worker. A first request ends in a fatal error and leaves global state pointing at freed memory. A second request then consumes that stale state before normal initialization resets it. Session upload progress, enabled by default and active even when an application never calls session_start(), is one such early consumer. On PHP 8.5, fatal-error backtraces provide the strongest demonstrated route.

For this flaw, PHP validated code execution against both mod_php and PHP-FPM. The FPM route relies on a suitable application operation that ends in a fatal error after startup; that operation need not be a security bug in its own right. FPM setups can also be exposed through a separate path when a front-end server passes PHP settings with each request.

PHP rates both flaws 9.2 under CVSS 4.0, the industry’s standard severity scale. The score reflects that attacks need specific conditions and preparation; it does not mean exploitation is rare in practice. Successful code execution runs with the permissions of the PHP worker account. That is not automatically full control of the operating system, but it usually means access to the application’s files, database credentials and any secrets the worker can read.

Researchers’ write-ups group the variants differently, and some use different labels for each CVE. This article follows PHP’s official advisories.

September to Mid-October: Preparing a Repair Behind Closed Doors

With working attacks in hand, the problem turned into a logistics exercise. A fix for PHP only protects anyone once it reaches the places PHP actually runs: Linux distributions, hosting control panels, container images, cloud platforms and managed services. To give them a head start, PHP worked under an embargo, a confidential period in which selected parties receive a fix before the public does.

PHP says Linux distributions and long-term support vendors received patches in advance. OpenAI’s account of the coordination describes security providers preparing firewall rules and detections, and says it briefed the US Office of the National Cyber Director, CISA and international partners. According to Cybersecurity Dive, the White House says the US government learned of the flaws on October 16. The public release was set for October 22 at 14:00 UTC.

All of this happened while PHP’s small security team was also absorbing a wave of AI-assisted reports. The Foundation says 15 PHP CVEs were published between July 1 and the release, while more than 100 other reports turned out to be invalid, duplicates or impossible to reproduce. Each one still had to be read and assessed by a person.

October 17 to 20: The Secret Starts to Slip

The first sign that someone outside the embargo knew something came on October 17, although nobody recognized it at the time. Amazon’s MadPot, a global network of decoy servers known as honeypots, recorded an exploitation attempt that day. Amazon only connected it to PHP2Shell later, in a threat-intelligence report published on October 21. The request came through a commercial anonymization network, and Amazon does not explain how the sender obtained exploit information before disclosure.

On October 20, the secrecy broke in public. At about 15:00 UTC, the two CVE numbers surfaced on forums and social media. A post on Hacker News claimed that two remote code execution flaws with a maximum severity score of 10.0 would be disclosed on October 22. It offered no technical details and got the score wrong, but security firm watchTowr confirmed that the flaws were real and under embargo.

PHP now faced two bad options. Releasing immediately would leave distributions without finished packages and most users without an easy way to update. Waiting two days would give attackers time to work from the leak. At around 19:30 UTC, PHP published an advance warning and moved the release forward by one day, to October 21 at 14:00 UTC, while reserving the right to publish even earlier.

Half an hour later, the situation worsened. According to the PHP Foundation, Calif mistakenly published a video at around 20:00 UTC showing its proof of concept working against several targets. The video was deleted, but copies spread on social media and revealed enough detail to help others build attacks faster. The Foundation adds that mitigation advice shared with some critical-infrastructure operators from 23:00 UTC may also have leaked.

October 21, Morning: Attackers and Defenders Move Before the Patch

By the early hours of October 21, attackers were no longer waiting for official details. Amazon says new attack attempts began reaching its sensors at around 02:00 UTC and continued for six hours from anonymized infrastructure. Different payloads and sources suggested several groups were involved, although Amazon could not tell whether those early attempts would have worked against real systems.

Defenders at the network edge moved first. At 03:02 UTC, nearly 11 hours before the release, Cloudflare switched on default protections for every customer using its web application firewall, including free accounts. A web application firewall (WAF) inspects traffic before it reaches a website. Cloudflare’s rules also check the server’s response, so a successful memory leak can be stopped on its way out. Attackers soon began altering their requests to slip past the filters.

Reports of attacks multiplied through the morning. At 07:34 UTC, WordPress security firm Patchstack logged reports from hosting partners of active exploitation incidents; by early afternoon, its own telemetry still showed only probing. Nine minutes after Patchstack’s entry, Cloudflare’s chief technology officer said early attacks were emerging. At 08:36 UTC, a scanner identifying itself as “php2shell-scan” reached 36 of ELLIO’s sensors within eight minutes.

Some governments decided not to wait for the patch. At 7 p.m. in Canberra (08:00 UTC), GovCMS cut direct access to its servers, citing advice from the Australian government’s cyber agency to disconnect. Pages already held in Akamai’s cache stayed online, but editors could no longer log in. Finland’s state IT center, Valtori, closed public inbound traffic to government web services from 09:45 UTC. By midday in the Netherlands, the DigiD website and the government portal MijnOverheid were offline.

The Embargo Dispute

One decision that morning became the most contested moment of the disclosure. At 07:41 UTC, more than six hours before the coordinated release, Chainguard published container images that already contained the fix. Its images were publicly available, so anyone could study the repair before PHP announced it. The PHP Foundation says Chainguard broke the embargo unilaterally and disregarded weeks of work by many parties.

Chainguard’s chief executive, Dan Lorenc, said he made the call because exploits were already being used in the wild, citing reports from other security vendors and the ease of exploitation. According to Socket’s account of the dispute, he later apologized for the extra stress on PHP’s maintainers but did not publish evidence for the reports he relied on.

The timing invites a link that the evidence does not establish. ELLIO’s first scanner arrived 55 minutes after Chainguard’s release, but Amazon had recorded attempts from 02:00 UTC that morning and on October 17, and the leak and video had circulated the evening before. What the episode does show is the tradeoff at the heart of coordinated disclosure: protecting one vendor’s customers early can expose details while everyone else is still preparing.

October 21, Afternoon and Night: The Patch Lands, the Attacks Multiply

PHP published the repaired versions shortly before the scheduled 14:00 UTC slot. Some providers delivered within minutes: Bref, which runs PHP on AWS Lambda, had its current runtime layers updated in every region about 31 minutes after the upstream release. Others needed hours, and some popular sources had nothing on day one. PHP warned that the volunteer-run Remi repository, widely used on Red Hat-style servers, would not have updates that day.

The release did not slow attackers down. Amazon says new proof-of-concept exploits appeared within hours and were used “almost immediately.” ELLIO watched the traffic evolve: at 16:05 UTC, requests stuffed with hundreds of empty file fields began targeting the out-of-memory flaw. By 20:40 UTC, an automated attack tool that had exploited another major web flaw earlier in the month added PHP2Shell and reached 123 sensors in 18 minutes. One captured payload downloaded a Linux program into the server’s temporary folder and ran it.

Cloudflare’s chief executive Matthew Prince later summed up the curve on X. He reported thousands of attempts in the ten hours before the announcement, tens of thousands in the first 45 minutes after it, hundreds of thousands within two hours, and millions by the following morning. At 22:36 UTC, Amazon’s report concluded that PHP2Shell was being broadly exploited in the wild.

Attempts are not the same as break-ins, though. Honeypots are built to be attacked, and a blocked request leaves no victim. watchTowr told SecurityWeek that nobody had yet succeeded against its sensors, but it did not expect that to last. The PHP Foundation says it found no functional public exploit at release time, although dozens of code repositories claiming to exploit the flaws soon appeared.

The quiet nature of the attack also makes victims hard to count. CrowdStrike, quoted by The Hacker News, says a successful attack can return a normal-looking response, leaving little more than a memory error in the server log. The absence of confirmed victims is therefore not proof that there are none.

A Global Wave of Precautionary Shutdowns

While attackers probed and patches spread, governments faced a choice that no patch could resolve in time: keep public services online and exposed, or switch them off and accept the disruption. Across at least a dozen countries on four continents, many chose to switch off. Their advice was strikingly uniform: patch immediately, and disconnect anything that cannot be patched quickly.

In Europe, the Netherlands was hit most visibly. The National Cyber Security Centre temporarily took its own website offline and urged organizations to keep affected systems offline until they were updated. Many followed: according to broadcaster NOS’s live coverage, the DigiD website, MijnOverheid, the parliament’s site, several hospitals, the football association KNVB and major charities went offline. The NCSC told NOS to treat every internet-facing PHP system as likely vulnerable until patched. DigiD logins continued to work on other government sites. A Reuters factbox, republished by Investing.com, adds the Port of Rotterdam and the websites of the country’s five largest political parties.

Elsewhere in Europe, the pattern repeated. Germany’s federal security agency BSI issued a warning at threat level 3 (orange) and advised disconnecting web servers that could not be patched promptly, news agency dpa reported. The federal IT provider ITZBund took several federal websites offline, and Berlin’s Charité hospital and the city portal of Mainz followed. In France, the Interior Ministry put all its websites into preventive maintenance at the request of cybersecurity agency ANSSI, including prefecture sites, while the national tax portal also showed a maintenance page that evening.

Belgium’s foreign ministry took its websites offline, although the national cybersecurity center recorded no attacks. Finland’s Valtori shut the state’s public web services. The Czech government took its website offline at 17:00 UTC. Denmark activated its National Operative Staff, the crisis body that convenes during major emergencies, at its lowest level. Danish minister Lisbeth Bech-Nielsen called it a global event rather than a cyberattack, as the Copenhagen municipality, the Road Directorate and the Meteorological Institute closed their sites.

At the European level, a joint statement from ENISA, the European Commission, CERT-EU, Europol and the network of national CSIRTs urged organizations to identify PHP deployments and patch them, with isolation where patching was not feasible. The UK’s NCSC told operators to consider taking systems offline if neither updates nor temporary mitigations could be applied quickly, and several UK council websites went dark.

In Asia and the Pacific, the decisions came in the evening, local time. At 21:55 in Tokyo, Prime Minister Takaichi urged operators on X to check for PHP, prepare for the 23:00 patch and take sites offline temporarily if they could not apply it quickly. Japan’s Ministry of Finance suspended some website content and services, and the online marketplace BASE, the art platform pixiv and the video site niconico went into emergency maintenance. By late that evening, the security blog piyolog had counted 54 Japanese organizations that had announced suspensions.

In Australia, the outages reached the government’s own cyber agency: cyber.gov.au and the Bureau of Statistics website went offline overnight. The Australian Signals Directorate said there was no indication its sites had been affected. Singapore’s Cyber Security Agency reported widespread exploitation attempts in an alert updated on October 22, while New Zealand and South Korea issued their own warnings.

In North America, CISA, the NSA and the FBI jointly urged organizations to update or take affected systems offline, Defense One reported. CISA added that it had not observed exploitation at the time of its alert. In Canada, the Cyber Centre issued a critical alert, and Evan Solomon, the minister for AI and digital innovation, said some federal websites had been taken offline as a precaution.

Beyond governments, community infrastructure followed suit. The Wikimedia Foundation took its Toolforge and Cloud VPS platforms offline, which host volunteer tools such as anti-vandalism bots, while Wikipedia itself stayed up. According to a Mashable roundup, the OpenStreetMap wiki, the wiki host Miraheze and several online games also shut down or entered maintenance, and 4chan switched to read-only mode.

Disconnecting carried real costs. Citizens lost access to government information, council documents in more than 100 Dutch municipalities and regions became unreadable, and Finland warned that some services may stay offline for weeks. It also had a technical limit: switching an application into maintenance mode does not help if the attack reaches PHP before the application starts. Effective restrictions had to stop traffic before it reached vulnerable PHP.

October 22: Where Things Stand

By the morning of October 22, the emergency had shifted from releasing a fix to getting it into millions of running systems. Patched versions are available for every supported PHP branch, many restricted services are back, and the most urgent question has moved from “Is there a fix?” to “Did anyone get in before it arrived?”

So far, the public evidence shows mass attempts but no confirmed break-in at a real organization. Japan’s Chief Cabinet Secretary Minoru Kihara said on Thursday morning that no damage had been reported at government agencies or critical-infrastructure operators. Australian ministers said no government websites had been breached, and Finland’s Valtori found no exploitation attempt against its systems. Neither CVE had been added to CISA’s Known Exploited Vulnerabilities catalog in its latest update, dated October 21.

The repair is still reaching servers unevenly. Some distribution channels had not shipped fixed packages by Thursday morning, including Debian’s testing and unstable branches, the Remi repository and Homebrew. Amazon Linux lists no planned fix for its PHP 8.1 package or the core PHP in Amazon Linux 2. Several hosts and cloud platforms were still rolling out updates or planning follow-up releases.

A side effect of the fix also needs attention. PHP maintainers have verified a separate SimpleXML and garbage-collection regression in 8.4.27 and 8.5.12, traced to an earlier change included in those releases. A proposed correction has maintainer approval but has not been merged, and no follow-up release has been announced. Operators using affected functionality should test those paths rather than delay the security update.

Three questions remain open. Nobody has publicly explained how the actor behind the October 17 attempt obtained working exploit information. Nobody knows how many systems were compromised quietly before patching. And nobody can say how many of the hundreds of thousands of servers on unsupported PHP will ever be repaired. That last question puts version numbers at the center of the response.

Which PHP Versions Are Fixed?

The October 21 security release supplies a repaired version for each supported branch. These are the first fixed upstream releases, not universal package numbers for every operating system:

Version numbers can mislead in both directions. Linux distributions often backport security repairs while keeping an older base version. Ubuntu’s security notice, for example, lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04, and a patched system still reports “8.3.6.” Plesk’s fixed builds for PHP 7.4, 8.0 and 8.1 keep their old version numbers, and only a build date of October 21, 2026, shows the repair. Chainguard’s fixed images also carry pre-fix version tags.

The reverse problem also exists: a version number alone cannot confirm a repair. OpenAI’s PHP version checker reads a site’s version from its response headers, so it can flag a backported server as vulnerable or return “unknown” when headers are hidden. The reliable evidence is the vendor’s package or build information for the PHP actually serving requests.

Older branches need particular care. PHP 8.1 and earlier no longer receive upstream releases, but the project published minimal source backports for 7.4, 8.0 and 8.1 for those who build PHP themselves. Ubuntu Pro, Plesk, Heroku, Red Hat and others cover some old branches through their own maintenance programs. None of this restores normal support.

PHP 8.2 receives this fix but reaches the end of security support on December 31, 2026. An emergency patch and a planned migration may both be necessary. Holding back an available security update until a major application upgrade is ready only extends the exposure.

What You Should Do Now

Because the fix lives in the server rather than the website, the right next step depends on who controls PHP. For a customer of a managed host, it is a concrete answer from the provider. For an administrator, it is evidence that every relevant process is running repaired code. The overview below summarizes the responsibilities; the sections that follow explain each one.

Everyday Internet Users

There is nothing to install on your phone or computer: PHP2Shell affects servers, not visitors’ devices. If a website you use was offline on October 21 or 22, that was most likely a precaution rather than a sign it had been hacked. The indirect risk is that a site attacked before it patched may have exposed data held on its server, including passwords. Unique passwords and two-step login limit the damage, and breach notifications from services you use deserve attention in the coming weeks.

Website Owners and Small Businesses

Start with your host, because the fix is theirs to apply on most hosting plans. Ask whether the environment serving your site has fixes for both CVE-2026-109618 and CVE-2026-109619, including any vendor backports. A useful answer names the repaired package or runtime and confirms it is running; “we use a recent PHP version” is not enough. In WordPress, Tools, Site Health, Info and Server shows the PHP version your site reports, but a backported fix may not change that number.

Several large hosts have published their own status. These are the providers’ statements from October 21, not independent verification:

Avoid shortcuts. Patchstack warns against unofficial “fix” plugins and copied code snippets, which cannot repair PHP and may break a site. If you run your own server on PHP older than 8.2 and cannot update, the WordPress project points to the UK NCSC’s advice to consider taking the site offline. The Drupal security team likewise calls a patched PHP the only complete mitigation.

Agencies and Freelancers Managing Client Sites

Treat this as an inventory problem first. List every client site, the hosting environment behind it and who controls PHP there, including staging sites, old campaign microsites and installations nobody has touched in years. Collect confirmation per hosting environment, because a provider’s announcement may cover its managed plans while leaving customer-managed servers out of scope. Record the answers: if a client later suspects a breach, the date each environment was patched will matter.

Online Stores

Shops face the same runtime question with more at stake, because checkout pages handle customer data and payment flows. Sansec confirmed unauthenticated code execution against Magento 2.4.9 and notes that its own Shield product cannot protect against this flaw; only updating PHP does. As a stopgap, it suggests blocking multipart form uploads and then testing checkout, or putting the store into read-only mode or offline. Any restriction must apply before traffic reaches PHP: the PrestaShop project’s guidance warns that application-level maintenance mode cannot block an attack that runs before the application starts.

After the update, check checkout, payment integrations, customer accounts and scheduled jobs. Business owners should also know in advance who will handle a suspected compromise. Patching restores a safer runtime; it does not reveal whether customer data or credentials were accessed beforehand.

Hosting Providers and Server Administrators

Begin with an inventory of every PHP runtime that serves HTTP requests: multiple versions, control-panel builds, bundled admin tools and exposed staging systems. Panels often ship their own PHP. Plesk’s internal engine, for example, needs a separate update, and on AWS Lightsail the Bitnami PHP installation is not updated by the system package manager. The Canadian Cyber Centre advises prioritizing internet-facing systems, but internal instances still need an owner and a decision.

Apply the fix through the package source you actually use. Ubuntu covers older releases through extended security maintenance, and Red Hat’s bulletin tracks fixes for its releases. Remi repository users had no update on release day and may need to switch to distribution packages or build from source.

Then restart every PHP process and verify what is running. A graceful Apache reload can keep the old PHP library loaded under mod_php, so a full restart is safer; LiteSpeed’s lsphp processes and long-running workers also need restarting. A command-line php -v check inspects a different binary from the one serving web pages, so confirm the version through a web request served by the same pool and remove any temporary test page afterward.

If a repair cannot be deployed promptly, PHP’s official advisory lists temporary measures. For the out-of-memory flaw, they include setting memory_limit=-1 where applications cannot override it, keeping post_max_size conservative and enforcing request-size and multipart limits at the web server or proxy. For the stale-state flaw, they include setting session.upload_progress.enabled=0 in php.ini or server configuration and, on PHP 8.5, fatal_error_backtraces=0, then restarting all workers. PHP stresses that these reduce exposure without making a server safe, and removing the memory limit can create its own availability risk. Settings circulating online beyond PHP’s list, such as session.use_strict_mode, are not part of the official guidance.

Developers Running Containers, Serverless Apps or Long-Lived Workers

For developers, a patched image in a registry protects nothing until it replaces what is running. Rebuild on an updated base image, redeploy and confirm that no old replicas, autoscaling templates or pinned images can bring the vulnerable version back. FrankenPHP compiles PHP into its binary, so it needs a new release or image rather than a system package update.

Managed platforms split responsibility in different ways. Google Cloud patches App Engine standard automatically, but Cloud Run only updates automatically when automatic base-image updates are enabled. Azure App Service rolls fixes out by release channel, with the Extended channel last, and leaves custom containers to customers. Heroku tells customers to redeploy, and Bref users need to update their dependency and redeploy.

Laravel users should check their hosting product. Laravel Forge installs PHP from a third-party repository that Ubuntu’s automatic security updates do not cover, so each PHP version must be updated deliberately, followed by restarts of queue workers, Horizon and Octane. According to Securing Laravel, Laravel Cloud patched automatically, while Vapor applications need a redeploy.

Security Teams Investigating Possible Compromise

Start the investigation window early enough. Amazon recommends reviewing activity back to at least October 17 and publishes indicators in its MadPot report. Some of those addresses belong to shared anonymization services, so a match calls for investigation rather than automatic blocking.

Several request patterns are worth searching for: POST requests containing the PHP_SESSION_UPLOAD_PROGRESS field, which Amazon highlights; multipart requests with hundreds of empty file fields or deeply nested field names; and unusually large or malformed PHPSESSID cookies, which Wiz associates with memory leaks. On the server side, Datadog’s analysis points to memory-exhaustion errors during request startup and shells spawned by PHP processes. None of these signals is proof by itself, since memory errors can have harmless causes.

Look beyond the web logs. Prophet Security’s checklist covers new files in the web root, new scheduled jobs, SSH keys or admin accounts, and unexpected outbound connections from web servers. Preserve evidence before cleanup removes it. Where intrusion is suspected, rotate every credential the PHP worker could read and rebuild from a clean, patched image. Be cautious with public “exploit” code for testing: most of it does not work as claimed, and unverified code from unknown repositories can itself carry malware.

Organizations Stuck on Legacy PHP

Ask your vendor for a specific, supported repair path. An old-looking version may be patched through extended maintenance, while a newer-looking custom build may lack the changes. Some vendors have said no fix is coming: Amazon Linux lists none for its PHP 8.1 package or Amazon Linux 2’s core PHP, and Google Cloud’s runtimes on PHP 8.1 and older will not receive one.

Where no maintained package exists, the options narrow to a properly maintained source repair, a migration, or removing internet exposure while the dependency is replaced. PHP’s source backports require someone able to build, deploy and maintain the result. They should not become a reason to postpone assigning an owner to an abandoned application.

What Comes Next

PHP2Shell will not end when the last restricted website comes back online. The next fixed date is December 31, 2026, when PHP 8.2 stops receiving security fixes, adding another large group of servers to the unsupported population. The hundreds of thousands of machines already on unsupported branches will remain the long tail of this incident for months, and attackers are likely to keep scanning for them.

The PHP Foundation has promised structural change. It says decisions on serious, stalled security fixes will move from consensus toward majority votes, and that leadership will step in sooner when a repair stalls. Its Ecosystem Security Team, announced in May, adds triage and coordination support, and the Foundation has asked companies, hosting providers and governments that rely on PHP to fund its security work.

The deeper change concerns time. A weakness that sat unresolved for two years became a working attack within two weeks once AI-assisted researchers focused on it, and attack attempts reached millions within a day of disclosure. Amazon’s security chief CJ Moses told The Hacker News that AI-assisted analysis is lowering the barrier for attackers, who can now act within hours or even minutes of a disclosure. For everyone who runs software on the internet, the lesson of PHP2Shell is that the gap between a fix’s release and its arrival on running servers is now where most of the risk lies.