PHP2Shell FAQ: 40 Questions Answered

As of 23 October 2026, the PHP project has fixed both PHP2Shell flaws in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October. Exploitation attempts are widely reported, confirmed successful compromises are not publicly documented, and the flaws are not in CISA's Known Exploited Vulnerabilities (KEV) catalog. This page answers the 40 questions we hear most, in plain language.

The one-line answer to most of them: PHP2Shell is a flaw in PHP itself, the software that runs most WordPress, Drupal and Joomla sites and a great deal of custom code. The fix is a patched PHP build on the server, followed by a restart of every PHP worker. Updating your CMS or plugins doesn't fix it.

Each answer is short and links to the guide that covers the topic in depth. If you only read one, read What Is PHP2Shell? A Plain-English Guide for Website Owners.

Basics

Start here if you have just heard the name and want to know what it is.

1. What is PHP2Shell?

PHP2Shell is the name for two critical flaws in the PHP engine, published on 21 October 2026. PHP says they "can allow unauthenticated remote code execution," which means an attacker could run their own commands on a web server without logging in. Because the bug is in PHP rather than any one application, it affects any site whose server runs an unpatched PHP build. The name covers two separate CVEs that were fixed together in the same PHP releases.

2. What are CVE-2026-109618 and CVE-2026-109619?

They are the two official identifiers. CVE-2026-109618 is about out-of-memory handling that "can interrupt PHP while internal request data is only partially initialized." CVE-2026-109619 is about internal state that "can survive after its backing memory has been freed" and get used by the next request on the same worker. The technical detail is in CVE-2026-109618 explained and CVE-2026-109619 explained.

3. What does a CVSS score of 9.2 mean?

CVSS, the Common Vulnerability Scoring System, rates severity from 0 to 10. PHP scored both flaws 9.2 under CVSS version 4.0 and calls them critical. Other scorers differ: NVD gives 9.8 and 8.1 under the older version 3.1, Red Hat gives 8.1 ("Important"), and Ubuntu rates them "Critical." The 10.0 score that circulated before release was wrong. PHP's CVSS 4.0 vector also marks attack complexity as high and says certain attack conditions must be present. Every scorer still rates it Important or higher.

4. Who found PHP2Shell?

Several teams. The PHP Foundation says researcher Ryan A at Calif reported the first remote code execution on 11 August 2026, with further reports from Wiz on 24 August and from OpenAI's Codex Security team. The PHP Foundation also says it had found "the first signs of the OOM problem" in 2024, and admits the delay in fixing it was "a structural failure." Researchers from Calif, Wiz and OpenAI are among the credited reporters on PHP's advisories. Wiz reported after Calif, despite some early headlines.

5. Is PHP2Shell the same as Log4Shell?

No. Log4Shell was a different flaw in different software, and the similar name doesn't mean the same mechanism. We won't rank them against each other. Wiz calls PHP2Shell "among the most severe vulnerabilities discovered in PHP," and that is reason enough to patch today.

Am I Affected?

Whether you need to act depends on whether PHP runs on a server you, or your host, control.

6. How do I know if my website uses PHP?

If your site runs on WordPress, Drupal, Joomla, Magento or a custom PHP application, it uses PHP. If you're not sure, ask your web developer or host which language your site runs on. Our guide on how to check your PHP version also shows where to find it. A site built on a hosted website builder usually doesn't run PHP on a server you control.

7. Is Shopify affected?

Shopify store owners have no PHP to patch, because Shopify runs and maintains its own servers. Any server-side fix is Shopify's job, not yours. Apps and integrations you connect to your store are separate services, so ask those vendors if they run PHP. The question that matters for you is whether you run any other site on your own hosting.

8. Is Wix or Squarespace affected?

The same logic applies. Wix and Squarespace customers don't manage the servers or the software on them, so there is nothing for you to install. If you also run a separate site, blog or booking tool elsewhere, check that one. Your remaining job on a hosted builder is the usual one: strong passwords, two-factor login and care with third-party apps.

9. Is my static site affected?

A purely static site, made of HTML, CSS and JavaScript files with no PHP on the server, can't be hit by a PHP flaw. Check for leftovers, though: a PHP contact form handler or an old admin tool on the same server means PHP is running there. Static sites built from a CMS can also keep PHP running on a separate, private server, which still needs patching even if visitors never reach it directly.

10. Does it matter if my site requires a login?

No. Both advisories rate the attack as needing no privileges, and PHP says the demonstrated attack on mod_php triggers "before any application code runs." A login page doesn't stand in the way, because the flaw sits below your application. Researchers demonstrated attacks against stock installs of WordPress, Drupal and Joomla with no account at all.

11. Which PHP versions are affected?

Upstream, every supported branch below the fixed releases: before 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Researchers say the bugs go back much further; Wiz and Calif both trace paths to PHP 5.4. The branch-by-branch table is in PHP2Shell fixed versions. Because the official advisories list only the supported branches, check older versions with your host or distribution rather than assuming they are fine.

12. What about PHP 7.4?

PHP 7.4 reached end of life on 28 November 2022, and the PHP project published no official release with the fix. It did publish minimal source-only backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. Most sites on 7.4 need a vendor-patched build from their host or distribution, or an upgrade. The same applies to PHP 8.0 and 8.1, which reached end of life on 26 November 2023 and 31 December 2025.

13. Is it true that 70% of the internet is vulnerable?

No. The 70% figure is PHP's share of websites whose server language is known; W3Techs puts it at 69.3%. That counts sites using PHP, not vulnerable sites, and many servers already run patched distribution builds. Censys counted about 3.08 million internet-facing hosts running PHP on 22 October. That is also a count of hosts using PHP, not confirmed vulnerable ones.

Fixing It

The fix is short to describe and easy to get slightly wrong. These answers cover the usual mistakes.

14. What do I need to install?

PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from the PHP project, or your Linux distribution's patched PHP package. Debian, Ubuntu, Red Hat, AlmaLinux, CloudLinux and cPanel have shipped fixed packages. If you're on shared hosting, your host installs them. A version number alone doesn't settle it: PHP 8.3.35 is vulnerable and 8.3.36 is fixed, so the patch level matters.

15. Do I need to restart anything?

Yes. PHP's advisory and every major vendor say to restart every PHP worker after updating, including PHP-FPM, Apache and any long-running PHP processes. Until a worker restarts, it keeps running the old, vulnerable code. If you are not sure every process restarted, a full service restart, or a server reboot in a maintenance window, removes the doubt.

16. I patched, but my PHP version number didn't change. Why?

Linux distributions backport fixes into the version they already ship. AlmaLinux says "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change." For example, Ubuntu 24.04's fixed package still reports PHP 8.3.6, so check the package version or changelog instead. The command-line PHP can also be a different build from the one serving your pages, so check the web server's PHP, not just php -v.

17. Will updating WordPress, Drupal or Joomla fix it?

No. WordPress.org says "No WordPress update is required or planned for these issues," and Drupal's security team names a PHP update as the only complete mitigation. Platform guides for WordPress, Drupal and Joomla cover each CMS. Updating your CMS is still good practice for other reasons; it just doesn't touch PHP.

18. Are the php.ini mitigations enough?

No. PHP says "only an update is a complete solution" and that its interim measures "do not make an installation safe." They reduce exposure to specific attack paths while you arrange the update. Each one, with its side effects, is in PHP2Shell interim mitigations. Settings applied with ini_set() or a .user.ini file don't work for the upload progress setting, because they apply too late in the request.

19. Should I set memory_limit=-1?

Only with care, and only as a stopgap. PHP lists it for CVE-2026-109618 but warns that "an underlying allocation failure can still reach the vulnerable path," and Calif notes it "removes PHP's memory cap, increasing the risk of memory exhaustion." PHP also warns against substituting RLIMIT_AS or RLIMIT_DATA limits, which can trigger the bug. If you use it, PHP says to set it where applications can't override it and to check that no other setting restores a finite limit.

20. Does PHP 8.5.12 fix everything?

It fixes the two PHP2Shell CVEs. On 23 October, PHP published an informational advisory about a separate, unlikely issue, CVE-2026-115560, that also affects patched releases. PHP suggests setting session.upload_progress.enabled=0 "until the next regular bugfix release," and says it is handling the fix in its regular release cycle. If you already turned upload progress off on 21 October, PHP says to keep it that way and no further action is needed.

21. Should I take my site offline?

If you can patch today, patch. If you can't, CISA says organizations that can't update immediately, or still run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated," and ENISA gives similar advice. If you do, Beazley advises a maintenance page or network restriction rather than disabling the PHP handler, which "can expose application source code and credentials." The UK NCSC also says to consider taking a system offline if you can't apply the temporary mitigations in time.

Hosting and Platforms

Who patches depends on who runs your server. These answers sort out the common hosting setups.

22. Does my web host patch PHP for me?

On shared and managed hosting, usually yes. On a VPS, dedicated or cloud server you manage, you or your IT team do it. Ask, and don't assume; our guide to website security by platform explains who is responsible for what. For example, Automattic says its hosted sites are safe, Google Cloud says App Engine standard apps on PHP 8.2 and newer are updated automatically, and cPanel, Plesk and CloudLinux have shipped fixed PHP packages.

23. What should I ask my host?

Ask three things in writing: is the PHP version my site uses patched for CVE-2026-109618 and CVE-2026-109619, were all PHP workers restarted, and when. If your site is on PHP 8.1 or older, also ask whether that build carries a vendor backport of the fix. Keep the reply. If you ever need to show when your site was patched, a dated written answer helps.

24. Does a web application firewall (WAF) protect me?

Partly. A WAF filters requests before they reach PHP, and Cloudflare says its free and paid WAF customers have been protected by default since 21 October 2026, 03:02 UTC. Rules don't catch every variant or configuration, so use a WAF to buy time, not instead of patching. Cloudflare also notes that its rule for the newer CVE-2026-115560 issue doesn't cover customers who changed session.upload_progress.name. Fastly has published protections too. Treat any WAF rule as a layer, not the fix.

25. Does Wordfence protect me?

Not as a fix. Wordfence and other WordPress security plugins are PHP code running inside PHP, so they can't patch the PHP engine, and on mod_php the first flaw fires before any WordPress code loads. They remain useful for spotting signs of a compromise; our overview of WordPress security plugins explains what they can and can't do. Wordfence's firewall runs as PHP code on your own server, which is different from a cloud WAF that filters traffic before it reaches PHP.

26. Is my WordPress.com site affected?

Automattic says "all sites hosted with Automattic, including those on WordPress.com, WordPress VIP, WP Cloud, Pressable, and Tumblr, are safe." Self-hosted WordPress on any other host needs its PHP checked. WordPress.org's own guidance points every self-hosted owner to Tools > Site Health > Info > Server to see the PHP version.

27. Should I leave WordPress because of PHP2Shell?

Not because of this. The flaw is in PHP, not WordPress, and what decides your risk is whether your server runs a supported, patched PHP build and whether someone applies patches quickly. Static or headless setups do reduce what runs on the public server, which is a sound reason to consider headless CMS development for the right project, but they bring their own maintenance, and a well-patched WordPress site is not doomed.

Detection

Patching closes the door, but it doesn't tell you whether anyone got in first.

28. How do I know if my site was hacked through PHP2Shell?

Look for unusual multipart or upload requests followed by memory errors or bursts of HTTP 500 responses, new PHP files in upload or temp folders, and shells or programs started by PHP or web server processes. Clean logs don't prove safety: PHP's advisory says "absence of an error in logs is not proof of safety." The full list is in was my site hacked through PHP2Shell. If you find signs of compromise, treat secrets held by PHP, such as database passwords and API keys, as exposed and rotate them.

29. How far back should I look?

At least 17 October 2026. Amazon says it saw an exploitation attempt that day, four days before disclosure, and both Amazon and Bitdefender recommend starting there. Sophos goes further and suggests reviewing administrator logins since 1 August 2026. Amazon says to "investigate from at least starting on October 17th," so use that as a minimum, not a limit.

30. Are there official indicators of compromise?

Not from the PHP project or Cloudflare as of 23 October. Amazon published a handful of IP addresses but says they include shared anonymization infrastructure and should be investigated rather than blocked. Most vendors share behavior to watch for, not file names or hashes. Be wary of any list of "PHP2Shell IOCs" that doesn't link back to a named, first-party source.

31. Is exploitation confirmed?

Attempts are. Amazon, watchTowr and Cloudflare all report attack traffic, and Cloudflare's CEO described "thousands of attempts" before the announcement. Bitdefender saw none in its telemetry as of 22 October, and watchTowr says the exploits being sprayed often "don't work at all, test for timing-based differences, or crash the target." Our PHP2Shell exploitation status tracker keeps the dated record. The safest summary as of 23 October 2026: widespread exploitation attempts are reported, and confirmed successful compromises are not publicly documented.

AI and the Future

AI tools played a real part in this story. Here is what the sources actually say, without the hype.

32. What did AI have to do with PHP2Shell?

Researchers used AI tools to find it. Wiz says it used "Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol," and that a single researcher did in a week what "would have taken a world-class team months." Calif says it used no special harness or private models, and OpenAI's Codex Security team was among the credited reporters. The PHP Foundation also thanked OSTIF and Quarkslab; the first signs of the bug surfaced in 2024 while a developer was fixing an issue Quarkslab had reported.

33. Will AI make this happen more often?

It will likely shorten the time between a patch and an exploit. Amazon says "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit." The same tools also help defenders: the PHP project says it scanned PHP with AI tools and that "a person makes every call and works on every patch." The practical answer is the same as ever: patch quickly.

34. Is PHP still safe to use?

Yes, when it's a supported, patched version. The PHP Foundation has written publicly about what went wrong in its process and what it is changing. Plan to stay on supported branches: PHP 8.2's security support ends on 31 December 2026. Debian, Ubuntu, Red Hat and AlmaLinux shipped fixed packages for many PHP streams on or soon after 21 October.

Conclusion

As of 23 October 2026, almost every PHP2Shell question comes back to the same steps: find out which PHP build serves your site, get it patched with the 21 October releases or a vendor package, restart every worker, and move off PHP 8.1 or older. WAFs and php.ini settings buy time, plugins can't patch the engine, and hosted platforms like Shopify and Wix handle their own servers. This is a moving story, so check the dated sources before acting on anything that may have changed. If you run your own server and need it patched quickly, our emergency PHP patching service can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions