Critical PHP Flaws (PHP2Shell): What to Do Now

If you own a website, especially a WordPress site, today is the day to check one thing: which version of PHP it runs.

On Wednesday, October 21, the people who maintain PHP released emergency fixes for two critical security holes, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell." Under the right conditions, they let an attacker who has never logged in run their own code on a web server. Attack attempts started before the fix was public, and they have since surged into the millions.

What happened: Two flaws deep inside PHP, the software behind WordPress and a huge share of the web, were disclosed and patched on October 21. Both are rated 9.2 out of 10 for severity. Governments and major websites spent the week patching, and some took pages offline as a precaution.

What this means for you: Web visitors have nothing to install. If you run a website, or pay someone to, make sure PHP itself has been updated. Updating WordPress or your plugins does not fix this.

What happened

PHP is a programming language that runs on web servers. When you load a WordPress blog, an online shop or Wikipedia, PHP is often the code quietly assembling the page.

PHP runs on 69.3% of websites whose server-side programming language can be identified, as of October 24. That's where the widely quoted "70% of the web" comes from. It counts sites that run PHP, not sites confirmed to be vulnerable or hacked.

The two flaws sit in parts of PHP that almost every web request touches: how it handles running out of memory and how it recovers from errors. In plain terms, PHP could be tricked into reusing scraps of memory it should have thrown away, and a skilled attacker could turn that into control of the server.

Every PHP installation that serves web pages is at risk, including the common setups PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache with mod_php is the highest-risk setup, because a working attack there can be triggered by a single request from a stranger, before the website's own code even runs.

The underlying problems are old. PHP's maintainers first spotted signs of the memory issue while fixing problems found in a 2024 security audit but found no concrete way to exploit it, and a fix stalled. The PHP Foundation now calls that delay "a structural failure."

The details

Attacks started before the fix

Amazon Web Services says one of its honeypots, a decoy server built to attract attackers, logged an attempt to exploit PHP2Shell on October 17, four days before the patches came out. AWS doesn't know how the attacker got the details while they were still secret.

On October 20, the two CVE numbers leaked online, so PHP moved its release up by a day, to 10 AM ET on October 21. Cloudflare CEO Matthew Prince said his network saw thousands of exploit attempts in the 10 hours before the announcement, and millions by that night.

Amazon's chief information security officer, CJ Moses, wrote that "PHP2Shell is now seeing broad exploitation attempts in the wild," adding that it was unclear whether any of the attempts AWS saw would have succeeded. When CISA, the US government's cybersecurity agency, published its alert on Wednesday, it said it had not observed successful exploitation, and its October 23 update left that line unchanged. The PHP Foundation's executive director, Elizabeth Barron, said "to our knowledge, there has been no successful attempt at remote code execution."

Sites went dark on purpose

Several national cybersecurity agencies, including the NSA and the UK's National Cyber Security Centre, advised organizations that couldn't patch right away to take systems offline. Wikipedia's parent organization took some systems down, and government agencies in Finland and the Netherlands pulled sites as a precaution. Some in the security world have taken to calling it "Black October."

Where AI comes in

Researchers at security firm Calif found a working attack in August, partly using advanced OpenAI tools alongside expert human knowledge of PHP. OpenAI and Google-owned Wiz independently found related attack paths with AI. Moses warns that AI-assisted analysis means more attackers "can act within hours or even minutes" once details go public.

What this means for you

If you just use websites: The flaws live on web servers, not on your phone or computer, so there's nothing for you to download. General safety advice, not specific to this incident: if a site you use asks you to change your password, do it from the site itself rather than a link in an email. Use a different password for every account. And be wary of emails about this bug urging you to click something.

If you run a small business or a website: This is your job, or your host's. Your host may already be updating PHP, but don't assume. Check.

What to do now: step by step

Find your PHP version. In WordPress, go to Tools > Site Health > Info > Server. Many hosting control panels also show it.
Compare it to the fixed versions in the table below. If your number is lower than the fixed one for its branch, you're probably not patched, unless your host or Linux vendor added the fix to an older build. Ask.
If someone else manages your site, email your host or web developer today and ask one question: "Has PHP been updated to a version that fixes CVE-2026-109618 and CVE-2026-109619?"
If you manage your own server, update PHP, or install your Linux distribution's patched package.
On PHP 8.1 or older? The PHP project no longer updates these versions. It did publish basic source fixes for 7.4, 8.0 and 8.1, and some vendors offer backported packages, but the safest path is moving to a supported version. CISA says systems that can't be patched, or still run 8.1 or earlier, should be taken offline until they're fixed. WordPress.org gives similar advice to people who run their own hosting.
Watch for signs of trouble. CISA says to look for PHP processes launching command shells or downloading tools. Unsure? Ask whoever runs your server.
Ask about one extra setting. On October 23, PHP flagged a related, unlikely attack path (CVE-2026-115560) and suggested setting session.upload_progress.enabled=0 until its next regular release. Your host will know what that means.

Fixed PHP versions (from php.net):

PHP branch	Update to	Notes
8.5	8.5.12	Supported
8.4	8.4.27	Supported
8.3	8.3.36	Supported
8.2	8.2.35	Supported until Dec 31, 2026
8.1 and older	No official release	Basic source backports for 7.4, 8.0, 8.1; check your vendor or upgrade

Temporary settings changes only reduce risk; updating is the only complete fix. CISA says a web application firewall may offer some protection in the meantime. WordPress itself needs no update: WordPress.org says none is required or planned, because the problem is in PHP.

Our read: if your site is a few years old and nobody has touched it since launch, assume it's on an old PHP version until you've confirmed otherwise.

Timeline

2024: A security audit leads PHP developers to the first signs of the memory problem.
Aug 11, 2026: Calif reports a working remote attack to PHP.
Oct 17: AWS logs the first known exploit attempt.
Oct 20: The CVE numbers leak online. PHP pre-announces the fix.
Oct 21, 10 AM ET: Fixed versions released. Attack attempts surge.
Oct 23: PHP issues a follow-up note on CVE-2026-115560.

What's still unknown

Whether anyone has actually been hacked. No successful break-in has been publicly confirmed so far, but security experts warn damage can take time to surface.
Who attacked early. AWS doesn't know how the October 17 attacker learned the details.
How many sites remain unpatched. There's no reliable public count.
What happens to old sites. Some unmaintained sites run PHP versions that no longer get official updates.

Critical PHP Flaws Put WordPress and Other Sites at Risk: What to Do Now