PHP2Shell: What to Do About the PHP Vulnerability (October 2026)

PHP2Shell is the name for two critical bugs in the PHP engine, CVE-2026-109618 and CVE-2026-109619, which PHP fixed on 21 October 2026 and rates 9.2 out of 10 (CVSS v4.0). Both can allow unauthenticated remote code execution, the "PHP RCE" in the headlines: someone on the internet makes your server run their commands, no password needed.

PHP is the program on your server that builds each page when a visitor arrives, and WordPress, its plugins and your theme all run on top of it. The bugs sit in the part of PHP that reads incoming requests. CVE-2026-109618 can corrupt memory when PHP runs out of it halfway through a request, and Sansec found it can also leak pieces of server memory, which may include passwords and login sessions. CVE-2026-109619 leaves one request's data in memory after it has been freed, where a later request can use it.

The PHP security advisory says every installation serving web requests is at risk, whether PHP runs through PHP-FPM, Apache's mod_php, php-cgi, FrankenPHP or LiteSpeed, and rates mod_php the highest risk. The PHP Foundation credits researchers at Calif, OpenAI and Wiz with reporting them.

The PHP vulnerability is being attacked according to Amazon, Cloudflare and watchTowr, but as of 23 October 2026 nobody has publicly confirmed a successful break-in, and the US agency CISA hadn't seen exploitation when it issued its alert. The sources disagree, so here's who said what:

• Amazon logged an attempt on its MadPot honeypots on 17 October, four days before the fix, and says PHP2Shell "is now being broadly exploited in the wild" (Tenable's PHP2Shell FAQ collects the quotes).
• Cloudflare reported attack traffic against its customers on 21 October, and watchTowr says it is seeing attempts against both bugs.
• CISA said on 21 October it had "not observed exploitation", and neither CVE was in its Known Exploited Vulnerabilities catalogue when I checked on 23 October.
• Sansec said on 22 October that mass exploitation looks less likely than it first feared, because an attack needs specific knowledge of the target server and the public proof-of-concept code failed against a default PHP install when a researcher tested it.

Singapore's Cyber Security Agency issued an alert on 21 October, updated on 22 October, telling organisations to update immediately, including PHP that sits inside third-party software. Its chief executive, Gwenda Fong, said "the threat is immediate", AsiaOne reported, and warned that many SMEs relying on outside IT vendors and hosting providers may not realise they're affected.

My read: the argument is about how many attacks work today. The bug is public, the fix exists and attack code gets better every week, so patch now. And don't run any "checker" script someone forwards you on WhatsApp. A fake scanner for last year's React2Shell bug turned out to carry malware.

Your website is affected by the PHP vulnerability if PHP runs on the server that builds its pages, which is the case for every WordPress, WooCommerce, Joomla, Drupal, Magento, OpenCart, PrestaShop and Laravel site. Whether you have to act depends on who runs that server. Find your row:

Not sure? If yourcompany.com/wp-admin shows a WordPress login, you're on WordPress, and the version-check guide in the series table below shows how to read your PHP number.

Look past the main site too. CSA and CISA both tell organisations to find every place PHP runs. For a small business that's often a forgotten staging copy, an old campaign microsite in the same hosting account, or a booking portal a vendor installed years ago. An unpatched staging copy is as open as the live site.

In the next 24 hours, get written confirmation that every server running your site has a patched PHP build and has been restarted, and take an off-server backup before anyone changes anything. In this order:

1. Find out who runs your server. That's your web host, or the developer or IT vendor who set up a cloud server. If the person who built the site in 2019 has left, search your email for the hosting renewal invoice.
2. Send them the message in the next section. It asks the four questions that matter. Or send me your address and I'll check it for free.
3. Check the version. You want 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later. A Linux vendor's patched build counts too, but its number looks different: Ubuntu 22.04's fixed PHP 8.1 still reports itself as 8.1.2. That's why the message asks for the date as well.
4. Confirm PHP was restarted. Canonical, which makes Ubuntu, points out that an updated package does nothing until the software using it restarts.
5. If it can't be patched today, ask for the stopgaps. PHP's advisory lists server settings that reduce the risk, such as session.upload_progress.enabled=0 in php.ini and a lower post_max_size. A plugin or a .user.ini file can't apply them properly.
6. On PHP 8.1 or older with no fix in sight, consider going offline. CISA's advice is to take unpatched PHP systems offline. Sansec has since said stores don't need to go offline, but for a shop or anything holding customer data on a PHP version with no fix, I'd follow CISA and put up a holding page with your WhatsApp number.
7. Back up first. Files and database, stored off the server, so a PHP change that breaks a plugin can be rolled back.
8. Look for warning signs since 17 October. Admin users you don't recognise, plugins nobody installed, a run of 500 errors, a warning from your host or Google. Your host can check the server-side signs Wiz and CISA list, such as PHP processes launching shells. You can report a break-in to SingCERT through CSA's reporting page.
9. Change passwords after patching. Because one of the bugs can leak server memory, I'd change admin passwords and any payment or email API keys if the site ran unpatched after 17 October.

Then put 31 December 2026 in your calendar. It's the last day PHP 8.2 gets security fixes.

Ask your host or developer which PHP version each of your sites runs, whether that build includes the 21 October 2026 fix, when it was installed and PHP restarted, and what they'll do about anything on PHP 8.1 or older. Copy this, fill in the brackets and send it by email or WhatsApp:

Hi [name], about the PHP security issue announced on 21 October 2026 (PHP2Shell, CVE-2026-109618 and CVE-2026-109619), can you please confirm for [yourcompany.com], and for any other sites or staging copies on our account:

1. Which PHP version is each site running now?
2. Is it the patched release (8.5.12, 8.4.27, 8.3.36, 8.2.35 or later), or a vendor build that includes the fix for both CVEs?
3. When was it patched, and has PHP been restarted since?
4. If any site is on PHP 8.1 or older, what are you doing about it, and when can we move it to 8.3 or 8.4?

Thanks, [your name]

A good reply names a version and a date. "Don't worry, our servers are secure" answers none of the four questions, so ask again. If they say the site can't move to a newer PHP because a plugin breaks, that's the real problem, and the WordPress update guide in the series table covers it.

A WordPress security plugin such as Wordfence or Kadence Security (formerly Solid Security) can't be relied on to stop PHP2Shell, because the plugin is itself PHP code and PHP says that on mod_php the confirmed attack can trigger before any application code runs. By the time the plugin loads, PHP has already read the request, and that's where these bugs sit. Sansec says its own store firewall, Shield, doesn't protect against them either.

So the PHP security update is a server job. On shared hosting the host does it. On a VPS or cloud server someone has to log in and do it, and on plenty of small business servers nobody has that job.

A firewall in front of your server is different, because it sees each request before PHP does. Cloudflare switched on PHP2Shell rules on 21 October, before the fix was released, on every plan including Free. Free sites didn't have to change anything, while paid plans should check their Managed Ruleset is set to block. Cloudflare still tells customers to patch, and CISA says a web application firewall "may provide some protection" until you do. Treat it as a seatbelt while the real fix happens.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 contain the fix, while PHP 8.1 and older get no release from the PHP project, so a site on them stays exposed unless its host or Linux vendor ships a backported fix. Support dates are from PHP's supported versions page:

For 8.1, 8.0 and 7.4, PHP published source patches for people who compile PHP themselves, which most businesses don't. What helps them is a vendor backport: Canonical patched PHP 8.1 on Ubuntu 22.04 under standard support, for example, while 7.4 on Ubuntu 20.04 needs an Ubuntu Pro (ESM) subscription. Ask your host which applies to you.

Plenty of sites are in this spot. Of the WordPress sites that report their PHP version to WordPress.org, about 36% run PHP 8.1 or older (7.4 alone is 16%) and another 24% run 8.2. That's roughly six in ten on a branch that's out of support or will be in ten weeks. A common cause is a plugin that broke on newer PHP, so the site was pinned to 7.4 "for now" years ago. Until this week that cost little.

This PHP security series has 13 guides, one for each situation you're likely to be in after PHP2Shell. Each one stands on its own, so pick the row that sounds like you.

Patch PHP if your site depends on WordPress features you use every week, such as WooCommerce, member logins or daily editing, and consider moving off PHP if it's mostly brochure pages pinned to an old PHP version with plugins nobody maintains. This is how I decide with clients:

• Stay and patch when it's on PHP 8.2 or newer, the plugins are maintained, someone updates it monthly, and it does real work: a shop, a members' area, bookings. A well-kept WordPress site is fine, and when WordPress is the right call, I build on it.
• Think about moving when it's pinned to 7.4, 8.0 or 8.1 because something breaks, runs on an abandoned page builder, and its pages change a few times a year at most.

Moving off PHP usually means a statically built site: pages built ahead of time and served as plain files from a CDN, so no PHP runs when someone visits and PHP2Shell has nothing to reach. terris.sg is built that way, with Astro on Vercel. In August I moved MET Interior's 176-page site from WordPress to Astro. It was a WordPress site I'd built for them in 2024, and its page builder was adding weight to every new page.

A static site still needs looking after, and I'd be misleading you if I said otherwise. Your domain registrar and DNS logins, the hosting or GitHub account that publishes the site, form and serverless endpoints, embedded third-party scripts and the npm packages it's built from can all be attacked. What it doesn't have is a PHP runtime, a database or a public WordPress login for bots to hammer.

On shared hosting, your host should update PHP at no extra charge; if your site runs on its own server, or nobody owns the job, a developer has to do it, and that's work I do for Singapore businesses. Ask your host first. SiteGround, which has a Singapore data centre, patched every server on 21 October and says customers don't need to do anything. I couldn't find a public notice from Vodien or Exabytes by the morning of 23 October, which may just mean they emailed customers directly, so ask. If the answer comes back clean, you don't need me.

Not sure, or nobody to ask? This is how I handle it:

1. A free PHP check. Send me your web address and I'll check which PHP version it runs, what it's built on and how old its theme and plugins are, free, and tell you what I find.
2. The fix, at a fixed price: if it needs the update, you get a fixed price in writing before I start, covering the PHP update and anything it breaks, from SGD 850. It's part of my website maintenance service.
3. Upkeep, so it's someone's job next time: a content retainer at SGD 550 a month covers updates, backups and security plus 5 hours of changes, month to month with 30 days' notice. My website maintenance cost guide compares the options.
4. Or a rebuild, quoted next to the fix so you can compare: a static site starts from SGD 2,535 for up to 10 pages in two to three weeks with my Starter website package, or SGD 3,545 for up to 20 pages live in seven days with the One Week Website, which has no self-editing CMS. If your team edits the site, Growth starts from SGD 7,585 with a CMS you edit yourself: WordPress, or a headless CMS that keeps the editing side off the public site.

WordPress is affected by PHP2Shell whenever it runs on an unpatched PHP version, because the flaw is in PHP underneath WordPress rather than in WordPress itself. Wiz demonstrated an unauthenticated attack against the then-latest WordPress, Drupal and Joomla container images, so a fully updated WordPress install doesn't help if PHP is old. Keep updating WordPress and plugins anyway. The fix for this one is the PHP update on the server.

SiteGround customers don't need to do anything about PHP2Shell, because SiteGround says it put protections on all its servers before the release and patched every server on 21 October 2026. Its post says no updates, settings changes or PHP version switches are needed. Two things are still yours: any site hosted somewhere else, such as an old microsite, and the 31 December 2026 end of PHP 8.2 if you picked that version.

PHP2Shell and wp2shell are different problems: wp2shell was a pair of flaws in WordPress core (CVE-2026-63030 and CVE-2026-60137), fixed in WordPress 6.9.5 and 7.0.2 on 17 July 2026, while PHP2Shell is in PHP, the language underneath, fixed on 21 October 2026. Updating WordPress fixed wp2shell, as Tenable's wp2shell FAQ explains. Updating PHP on the server fixes PHP2Shell. A WordPress site needs both.

PHP is still safe to use when it's on a supported version and kept updated, which in October 2026 means PHP 8.2 or newer, with a move to 8.3 or later before 8.2's support ends on 31 December 2026. Every widely used language gets security bugs, and PHP's team fixes them regularly: there were security releases on 7 May, 2 July, 30 July and 24 September 2026 before this one. The risk sits with sites nobody updates and with versions PHP no longer supports.

If your developer says the site can't run PHP 8, it's stuck on PHP 7.4 or older, which has had no official security fixes since 28 November 2022 and got no release for PHP2Shell, so the blocker needs fixing now. Usually it's one or two plugins, a theme or a page builder that hasn't been updated in years. Ask for the list of what breaks. Sometimes replacing them is a day's work, and sometimes it's the point where a rebuild costs less than the repairs.