PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. They can let an attacker run their own code on a web server without logging in.

How do I check if my WordPress site is vulnerable to PHP2Shell?

Go to Tools, Site Health, Info tab, Server section in WordPress and read the PHP version. Your site is affected unless that version is 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched build from your distribution.

Will updating WordPress or installing a security plugin protect me from PHP2Shell?

No. The vulnerabilities are in the PHP interpreter, not in WordPress, and the attack can fire before any plugin code runs. Only updating PHP fixes it.

What should I do if my WordPress site runs on PHP 8.1 or older?

Switch to a supported PHP branch, because the PHP project has released no official fix for 8.1 and older. WordPress recommends PHP 8.3 or newer, and you should test the switch on a staging copy first.

PHP2Shell: what WordPress site owners need to do about the critical PHP vulnerabilities

Key takeaways

PHP2Shell is two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a server without logging in. php.net fixed both on October 21, 2026, and every WordPress site runs on PHP, so every one needs a fixed version or a patched build. arvindkumar.ca
Check your site in Tools, Site Health, Info tab, Server. The PHP version there is the one that matters, and PHP SAPI shows how PHP runs (apache2handler, fpm-fcgi and litespeed are all at risk). arvindkumar.ca
Updating WordPress, themes or plugins does not help, and security plugins cannot block the attack, because the flaw sits underneath WordPress and fires before it loads. Only a PHP update fixes it. arvindkumar.ca
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some distributions, such as Ubuntu, patch their own build without changing the version number, so check the distribution’s security notice for the two CVE numbers. arvindkumar.ca
On managed hosting, ask your host by name about PHP2Shell and both CVE numbers, then confirm in Site Health. On your own server, install the update, restart every PHP worker and repeat for every site. arvindkumar.ca
If you cannot update yet, some measures reduce exposure, such as turning off session upload progress and lowering post_max_size, but nothing short of the update makes a site safe. If none are possible, take the site offline or put it behind access control. arvindkumar.ca
PHP 8.1 and older get no official release, so move to PHP 8.3 or newer unless a distribution or host backports the fix. After patching, check for unexpected PHP files and admin accounts, and rotate the database password, salts and API keys if your site was exposed. arvindkumar.ca

Summarised from this post, formatted for answer engines.

What is the PHP2Shell vulnerability?

PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run their own code on a web server without logging in. php.net fixed both on October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Every WordPress site runs on PHP, so every WordPress site needs one of those versions, or a patched build from its host or Linux distribution.

Last updated October 22, 2026, 5:30 pm Toronto time. New developments go at the top of the timeline below.

What happened with PHP2Shell, and when?

It went from private research to a leak, to attacks, to an emergency fix in about a day. Here is the order of events, newest first. Times are Toronto time, with UTC in brackets.

Skip Timeline

Thursday, October 22, 3:50 pm (19:50 UTC): CloudLinux says fixed PHP is now in its stable repositories for every affected version

CloudLinux updated its status page: “Fixed native PHP packages from the CloudLinux OS repositories are now in the stable channel for every affected version.” Native means the PHP that comes with the operating system itself: PHP 8.3 on CloudLinux 10; 8.0, 8.1, 8.2 and 8.3 on CloudLinux 9; 7.2, 7.3, 7.4, 8.0 and 8.2 on CloudLinux 8; and PHP 5.4 on CloudLinux 7 through TuxCare ELS. Earlier in the day, CloudLinux had said most of those builds were still in testing. The alt-php packages most shared hosts use got there first: CloudLinux said at 9:19 pm (01:19 UTC) on October 21 that fixed alt-php was in its stable repositories for CloudLinux 7, 8 and 9. At 10:31 am (14:31 UTC) it explained that fixed alt-php and ea-php packages carry a backported fix, so they keep a lower PHP version number: “These packages contain the fix for both CVEs, even though the PHP version number is lower.” To check a server, CloudLinux suggests rpm -q --changelog on the package and looking for the two CVE numbers, or, for its native PHP 8.2 and 8.3, rpm -q php-cli, which should show 8.2.35 or 8.3.36 or later. If you are on shared hosting that runs CloudLinux, the fix for your PHP version should now be available to your host, so ask whether it is installed.

Thursday, October 22, 4:26 am (08:26 UTC): Kinsta says every site on its platform has the PHP fix

Kinsta marked its status page incident resolved: “All sites are protected, the PHP security updates have been rolled out across the platform.” That covers every PHP version Kinsta offers, from 7.4 to 8.5, which were still rolling out a minute earlier. Kinsta says it has no evidence of any breaches linked to the vulnerabilities, and that its Cloudflare firewall rules and local configuration changes stay in place for all sites until further notice. If your WordPress site is on Kinsta, there is nothing for you to do.

Wednesday, October 21, 5:15 pm (21:15 UTC): AlmaLinux ships fixed PHP for AlmaLinux 8, 9 and 10

AlmaLinux updated its post to say patched PHP packages are rolling out to its production repositories for every PHP stream on AlmaLinux 8, 9 and 10, so you no longer need its testing repository to get them. The update is stamped 5:15 pm (21:15 UTC) on October 21, although when I checked at about 8:15 pm the post still said “Patches in progress”, so it may have gone up later than that, and mirrors can take a few hours to catch up. AlmaLinux backports the fixes, so the PHP version number does not change: AlmaLinux 10’s default PHP, for example, is fixed in package version php-8.3.33-1.el10_2.alma.1, and the php:8.3 stream on AlmaLinux 9 in php-8.3.33-1.module_el9.8.0+328+1fdeb728.alma.1. It has also patched older streams that Red Hat no longer supports, such as php:7.2, 7.3 and 8.0 on AlmaLinux 8 and php:8.1 on AlmaLinux 9, but says future fixes for those are not guaranteed. If your WordPress site runs on AlmaLinux, update the php packages with dnf, restart PHP-FPM (or Apache, if you use mod_php), and check the installed package version with rpm -q php-common rather than php -v.

Thursday, October 22, 2:44 am (06:44 UTC): Hostinger finishes installing the fix on its hosting servers

Hostinger updated its post to say it completed the rollout of patched PHP at 2:44 am (06:44 UTC): “PHP’s fix is now installed on all Hostinger hosting servers except VPS.” When The Repository reported on hosts a couple of hours earlier, Hostinger was still installing it. If your WordPress site is on any Hostinger plan except VPS, there is nothing for you to do. VPS customers manage their own PHP, so on a Hostinger VPS, updating PHP and restarting it is still your job.

Wednesday, October 21, 9:20 pm (01:20 UTC on October 22): GoDaddy patches Windows Hosting and starts on its Web Hosting servers

GoDaddy updated its post again: “We have patched all PHP versions on Windows Hosting. You don’t need to take any action.” Its Web Hosting servers, which were waiting on a vendor at its previous update, are next: “We have the patches from our vendor and are deploying them to all Web Hosting servers now.” GoDaddy says the mitigations stay in place until that finishes. If your WordPress site is on GoDaddy Web Hosting, I’d check Site Health, Info, Server for a fixed PHP version, or ask GoDaddy whether your server is done.

Thursday, October 22: Cloudflare’s CEO says PHP2Shell attack attempts have reached the millions

Cloudflare’s CEO, Matthew Prince, has posted figures for the attack traffic Cloudflare is seeing. According to The Register’s report, Cloudflare saw thousands of exploitation attempts in the 10 hours before the vulnerabilities were disclosed, then tens of thousands within 45 minutes, hundreds of thousands within two hours, and then millions. Cybernews quotes his post: “hundreds of thousands within 2 hours, and millions now.” The Register also reports that attackers keep changing their payloads to get past Cloudflare’s firewall rules, and that Cloudflare stressed the rules are no substitute for patching. These are attempts, not confirmed break-ins, and I could not open Prince’s post on X myself, so the figures are his, as passed on by those two outlets. If your site is not on a fixed PHP yet, assume it is being probed.

Wednesday, October 21, evening: Chainguard says it shipped its fix early because people were already being attacked

The PHP Foundation’s account, further down this timeline, says Chainguard “unilaterally broke the embargo” when it published built images containing the fix at 3:41 am (07:41 UTC) on October 21. Chainguard’s CEO, Dan Lorenc, answered in The Register’s report, published at 8:02 pm (00:02 UTC on October 22). He said Chainguard “didn’t leak”, that it learned of the issue the previous Friday and found the same bugs independently, and that “People were getting hit in advance” of the official disclosure, “so we made the call to ship the fixes under that.” Who was right is a question for the PHP project and the security industry. For WordPress site owners it changes nothing: update PHP.

Thursday, October 22, 3:04 am (07:04 UTC): SUSE fixes PHP on its older enterprise releases, including PHP 7.4 and 8.0

SUSE published two more advisories, SUSE-SU-2026:4843-1 and SUSE-SU-2026:4844-1, and its page for CVE-2026-109618 now lists many more released fixes. SUSE Linux Enterprise Server 15 SP6-LTSS, and SLES for SAP 15 SP6, have PHP 8.2 fixed in php8 package version 8.2.35-150600.3.39.1. On SLES 15 SP4-LTSS and SP5-LTSS, PHP 8.0 is fixed in package version 8.0.30-150400.4.80.1. PHP 7.4, package version 7.4.33-150400.4.81.1, is listed as fixed for SLES 15 SP4 to SP7, although the same page still lists some PHP 7.4 packages as in testing, so check that your update tool offers it. openSUSE Tumbleweed has PHP 8.5.12. When I checked, the page did not mention SUSE Linux Enterprise Server 16.0 or openSUSE Leap, so if you run either, keep an eye on SUSE’s page.

Thursday, October 22, 12:38 am (04:38 UTC): more WordPress hosts report where their patching stands

The Repository, a WordPress newsletter, gathered statements from WordPress hosts and security firms, and I checked the ones I could open. Hostinger says it is installing PHP’s fix on every server and that customers on every plan except VPS have nothing to do; VPS customers who manage their own PHP need to update it now. Kinsta’s status page said at 3:04 pm (19:04 UTC) on October 21 that patched PHP 8.3 and 8.5 were rolling out, with 8.4, 8.2, 8.1 and 7.4 still being validated; The Repository reports that every version was rolling out by 7:25 pm (23:25 UTC). Bluehost says most of its servers are patched, and that while it applies mitigations, customers “may see limits on the file size you can upload.” According to The Repository, WP Engine finished deploying its patches at 9:19 pm (01:19 UTC), and Wordfence got code execution in its lab through one of the two vulnerabilities, while the other mostly crashed or restarted PHP. Wordfence also suggests keeping server and firewall logs from at least 48 hours before the release. Sucuri says its firewall was already blocking some of the attack patterns and it has added more rules, but “WAF protection does not replace patching.”

Thursday, October 22: Plesk fixes the PHP that runs its own control panel, in Plesk Obsidian 18.0.81 Update 4

Plesk updated its support article again; it now shows “Updated October 22, 2026 00:00”. sw-engine, the PHP that runs the Plesk panel itself, now has a fix: “Fixes for sw-engine (PHP engine used by Plesk itself) are already available in Plesk Obsidian 18.0.81 Update 4”, for both Plesk for Linux and Plesk for Windows. Plesk lists 18.0.81 up to Update 3, and 18.0.80 Update 10 and older, as affected. Servers on 18.0.80 still have to wait: Plesk says “The fix for sw-engine in Plesk Obsidian 18.0.80 is still pending”, planned as Update 11. This is separate from the PHP versions that serve your WordPress sites, which the earlier Plesk entries cover. If you run your own Plesk server, install Plesk’s updates and check that it reports 18.0.81 Update 4 or later.

Wednesday, October 21, 5:02 pm (21:02 UTC): ELLIO counts 25 addresses sending PHP2Shell attacks, with no confirmed break-in yet

ELLIO has now published its own report, which backs up the first figure The Hacker News passed on. The first PHP2Shell request reached its sensors at 4:36 am (08:36 UTC) on October 21, five and a half hours before the fix was public, from a scanner with the user agent php2shell-scan/109618. Activity grew after the release: at 12:05 pm (16:05 UTC) one address sent 49 out-of-memory attack requests in twenty minutes, and from 4:40 pm (20:40 UTC) another reached 123 of its sensors in eighteen minutes. By 5:00 pm (21:00 UTC), 25 addresses had sent PHP2Shell requests, which ELLIO groups into a handful of tool families rather than 25 separate attackers. Some of the requests carry a loader that downloads a program into /tmp and runs it. ELLIO also says “No public source has reported a confirmed compromise yet.” Its report lists signs to look for in your logs, which I have added to the section on checking whether your site was hit.

Wednesday, October 21: cPanel’s own release notes confirm fixed PHP in EasyApache 4

cPanel’s release notes for EasyApache 4 25.91, dated October 21, say the release fixes CVE-2026-109618 and CVE-2026-109619 in its ea-php74 to ea-php85 packages. That is cPanel’s own confirmation of what GoDaddy and InMotion Hosting reported earlier, and it covers PHP 7.4, 8.0 and 8.1, which get no official release from the PHP project. The notes do not list the fixed package versions, and the detailed EasyApache 4 change log had not caught up when I checked. If you run your own cPanel server, run the EasyApache 4 updates in WHM, then restart Apache and PHP-FPM.

Thursday, October 22: VulnCheck counts more than a million exposed hosts on PHP with no official fix

The Hacker News gathered more numbers from security firms. According to its report, VulnCheck found PHP on 2,608,039 internet-facing hosts: more than 700,000 run PHP 3.x to 7.3 and about 400,000 run PHP 7.4 to 8.1, versions that get no official release, against 403,000 on the supported 8.2 to 8.5. VulnCheck also spotted two hosts scanning with the user agent php2shell-scan/109618. ELLIO says the first PHP2Shell request reached its sensors at 4:36 am (08:36 UTC) on October 21, less than an hour after Chainguard published its fixed images, and Pantheon, which hosts WordPress and Drupal sites, says it has blocked more than 60,000 suspicious requests probing the vulnerability. I have not seen these firms’ own reports yet, so treat the numbers as theirs, passed on by The Hacker News.

Thursday, October 22: Amazon Linux 2 has fixed PHP 8.2 for both vulnerabilities

Amazon’s tracker pages for CVE-2026-109618 and CVE-2026-109619 now agree. When I checked at about 2:55 am, both listed PHP 8.2 from the Amazon Linux 2 Extras as fixed in ALAS2PHP8.2-2026-015, along with php8.2 to php8.5 on Amazon Linux 2023, and neither showed any package as “Pending Fix”. The php package in the Amazon Linux 2 core repository, and php8.1 on Amazon Linux 2023, are still “No Fix Planned”.

Wednesday, October 21, 6:36 pm (22:36 UTC): Amazon says PHP2Shell is now broadly exploited, and was first tried on October 17

Amazon’s CISO, CJ Moses, wrote on the AWS Security Blog that MadPot, Amazon’s network of honeypots, recorded an exploitation attempt on October 17, four days before the vulnerabilities were disclosed, from an IP address on a commercial anonymisation network. Amazon says that suggests a threat actor, and that it is unclear how they got the details so early. It saw several proof-of-concept exploits from about 10:00 pm (02:00 UTC) on October 20, while the fix was still under embargo, and more within hours of the release, which it saw used against its sensors “almost immediately.” Its verdict: “PHP2Shell is now being broadly exploited in the wild.” That is a stronger claim than Huntress made at 4:30 pm, when it had seen no attacks on its partners’ systems. Amazon says upgrading PHP is the only complete fix. Until you can, it suggests blocking multipart file uploads after checking what that breaks, looking for POST requests that contain PHP_SESSION_UPLOAD_PROGRESS, and checking servers for unexpected processes or changed files. It also says to start any investigation from October 17, not October 21.

Wednesday, October 21: Amazon Linux 2023 now has fixed packages for PHP 8.2 to 8.5

Amazon’s advisory pages now load, and each one lists both CVEs. On Amazon Linux 2023, the fixed package versions are php8.2 8.2.35-1.amzn2023.0.1 in ALAS2023-2026-3301, php8.3 8.3.36-1.amzn2023.0.1 in ALAS2023-2026-3302, php8.4 8.4.27-1.amzn2023.0.1 in ALAS2023-2026-3303 and php8.5 8.5.12-1.amzn2023.0.1 in ALAS2023-2026-3304. That settles the php8.5 question from my last entry: the tracker page for CVE-2026-109619 now lists php8.5 as fixed too, along with php8.5 on the Amazon Linux 2027 Preview, in ALAS2027-2026-243. That page still shows php8.2 on Amazon Linux 2023 as “Pending Fix”, but the php8.2 advisory itself names both CVEs. php8.1 is still “No Fix Planned”. Remember to install with sudo dnf upgrade --releasever=latest, then restart PHP-FPM or Apache.

Wednesday, October 21, evening (October 22 UTC): Amazon Linux 2023 ships fixed PHP

Amazon Linux has started shipping its fixes. Its security tracker now lists the php8.2, php8.3 and php8.4 packages on Amazon Linux 2023 as “Fixed”, in advisories ALAS2023-2026-3301, 3302 and 3303, dated October 22 in UTC. The tracker’s two CVE pages do not agree on the rest yet. The page for CVE-2026-109618 lists php8.5 as fixed too, in ALAS2023-2026-3304, while the page for CVE-2026-109619 still says “Pending Fix” for it. For PHP 8.2 from the Amazon Linux 2 Extras it is the other way round: fixed in ALAS2PHP8.2-2026-015 on the CVE-2026-109619 page, still pending on the other. The advisory pages themselves would not load when I tried, so I can’t give the fixed package versions yet. php8.1 on Amazon Linux 2023, and the php package in the Amazon Linux 2 core repository, are listed as “No Fix Planned”. If your WordPress site runs on Amazon Linux 2023, note that each server is locked to its release, so a plain dnf upgrade can report “Nothing to do”. Amazon’s documentation uses sudo dnf upgrade --releasever=latest to install updates from the latest release; then restart PHP-FPM or Apache.

Wednesday, October 21: Red Hat fixes PHP on RHEL 10

Red Hat published two more advisories, both rated Important, that fix both vulnerabilities on Red Hat Enterprise Linux 10, including its 10.2 Extended Update Support and Extended Life Cycle subscriptions. RHSA-2026:87070 fixes the default php package, PHP 8.3, with version 8.3.36-1.el10_2, and RHSA-2026:87071 fixes the php8.4 package with version 8.4.27-1.el10_2. Both also fix a third, less serious vulnerability, CVE-2026-91765, a denial of service in PHP’s SOAP parser. That closes the RHEL 10 gap I mentioned in the earlier Red Hat entries. AlmaLinux, a free distribution built to match RHEL, said at 10:36 am (14:36 UTC) that its fixes for AlmaLinux 8, 9 and 10 were in progress, with test packages expected later in the day. When I checked at about 8:15 pm, its post still said “Patches in progress”, so if your server runs AlmaLinux, keep an eye on that post.

Wednesday, October 21: SUSE ships a fix for SLES 15 SP7, but Amazon Linux has none yet

SUSE’s page for CVE-2026-109618 now lists a released fix for SUSE Linux Enterprise Server 15 SP7, its SAP edition and its Web and Scripting module, with the php8 package version 8.3.36-150700.3.24.1. The fix for SUSE Linux Enterprise Server 16.0, PHP 8.4.27, is still listed as in progress, and SUSE’s php7 packages and openSUSE Leap are still listed as affected. Amazon Linux has not shipped a fix: its security tracker lists php8.2, php8.3, php8.4 and php8.5 on Amazon Linux 2023, and PHP 8.2 from the Amazon Linux 2 Extras, as “Pending Fix”, and php8.1 on Amazon Linux 2023 as “No Fix Planned”. A member of the Amazon Linux team replied on GitHub: “We are aware of those Critical CVEs and actively working on delivering an update asap.” If your WordPress site runs on Amazon Linux 2023 with PHP 8.1, I’d plan the move to PHP 8.3 now rather than wait for a fix that is not coming.

Wednesday, October 21, 4:40 pm (20:40 UTC): Huntress still has not seen attacks on the systems it watches

Huntress, whose advice on spotting a break-in I point to below, updated its write-up: “As of October 21 at 4:30pm ET, Huntress has not observed in-the-wild exploitation on partner systems.” It also noted that several researchers, including Calif and Wiz, have now published the technical details of the vulnerabilities. So the reports still differ: Patchstack reported confirmed exploitation incidents early that morning, Hadrian reported exploitation “at scale”, and watchTowr told SecurityWeek it had seen attempts but no successful ones. With the details now public, I would not count on that lasting. It changes nothing about what to do: update PHP.

Wednesday, October 21: OVHcloud says shared hosting gets fixed PHP automatically, but VPS and dedicated servers are up to their owners

OVHcloud published a post on the two vulnerabilities for customers who run their own servers. It says “WebCloud and shared hosting customers will automatically get an updated PHP component.” VPS and Bare Metal customers are on their own: OVHcloud says it does not touch their servers without their consent, so they need to update PHP to a fixed version and then restart PHP, which OVHcloud calls “the step most often forgotten.” If your WordPress site is on an OVHcloud VPS or dedicated server, that job is yours.

Wednesday, October 21, 4:18 pm (20:18 UTC): CloudLinux starts shipping fixed PHP for shared hosting servers

CloudLinux, the operating system behind many shared hosting servers, posted on its status page: “Fixed packages for the versions below are already available in our stable repositories.” On CloudLinux and AlmaLinux 8 and 9, the first fixed versions are alt-php 5.2, 5.6, 7.4, 8.0 and 8.4, with similar lists for CloudLinux 6, 7 and 10, Ubuntu, Debian and Alpine. alt-php 8.1, 8.2, 8.3 and 8.5 on CloudLinux 8 and 9 were not on that list. CloudLinux said the remaining versions were rolling out continuously, with the bulk expected by about 5:15 pm (21:15 UTC) and alt-php 8.5 by about 6:30 pm (22:30 UTC). A regular package update installs them; a security-only update will not see them until CloudLinux adds the advisory data. When I checked at about 6:20 pm, the page had no newer update. This is the release InMotion Hosting said its shared, reseller and WordPress servers were waiting for, so if you are on shared hosting, I’d ask your host whether the fixed alt-php for your PHP version is installed yet.

Wednesday, October 21: Red Hat fixes PHP 8.3 on RHEL 9 and PHP 7.4 on RHEL 8

Red Hat published two more advisories, both rated Important. RHSA-2026:87079 fixes both vulnerabilities in the php:8.3 module stream on Red Hat Enterprise Linux 9, with the php package version 8.3.36-1, including its 9.8 Extended Update Support and Extended Life Cycle subscriptions. RHSA-2026:87080 fixes them in the php:7.4 module stream on RHEL 8 and RHEL 8.10 Extended Life Cycle, with the php package version 7.4.33-8. PHP 7.4 gets no release from the PHP project, so this is the kind of vendor backport php.net told users of old PHP to ask for. I have not yet seen Red Hat notices for RHEL 10, or for its other PHP streams on RHEL 8 and 9.

Wednesday, October 21, 3:30 pm (19:30 UTC): GoDaddy patches Managed WordPress, but its shared hosting waits

GoDaddy updated its post on the vulnerabilities: “We have patched all PHP versions on Managed Hosting for WordPress,” so those customers have nothing to do. Its Web Hosting and Windows Hosting servers are not patched yet. GoDaddy says it is waiting for its vendor to supply patched versions of the custom PHP packages those servers use, has added mitigations in the meantime, and will apply the fix once the packages arrive. VPS customers manage their own PHP and need to update it themselves; for those running cPanel, GoDaddy says cPanel has added fixed PHP builds to EasyApache 4, such as ea-php82 8.2.35, and backported the fix to its PHP 7.4, 8.0 and 8.1 packages. InMotion Hosting describes a similar split: its dedicated servers are patched, while its shared, reseller and WordPress servers are waiting for CloudLinux’s alt-php packages. If you are on shared hosting anywhere, I’d ask whether your server has the fixed PHP yet, or only mitigations.

Wednesday, October 21: Automattic and SiteGround tell WordPress customers there is nothing to do

Two large WordPress hosts have spoken to their customers. At 12:16 pm (16:16 UTC), Automattic posted: “If your site is hosted on WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr, your site is already protected.” It says it worked closely with the PHP Security team to protect those sites as soon as possible, and “There is nothing you need to do.” It does not say how, or which PHP versions those platforms now run. SiteGround posted earlier, at 7:30 am (11:30 UTC), before the fix was out. It said it had rolled out server-level mitigation rules across all its servers, that “We disabled the affected functionalities on all supported PHP versions,” and that customers have nothing to do. It promised to update the post once PHP published its release; when I checked, it had not. php.net says measures short of the update do not make an installation safe, so if you are on SiteGround, I’d look for a fixed PHP version in Site Health once SiteGround confirms it.

Wednesday, October 21: Debian ships its fix for Debian 12

Debian published long-term support advisory DLA-4848-1, which fixes both vulnerabilities in Debian 12 (bookworm) with the php8.2 package version 8.2.35-1~deb12u1. Debian 12 had been the gap in Debian’s fixes: after Debian 13 was fixed, its php8.2 package was still listed as vulnerable. Debian’s tracker page for CVE-2026-109618 now shows it as fixed. The page for CVE-2026-109619 had not caught up when I checked, but the advisory covers both.

Wednesday, October 21: Plesk fixes its older PHP builds and Plesk for Windows

Plesk updated its support article again. Its PHP 7.4, 8.0 and 8.1 builds for Linux now have fixes, but they keep the same version numbers, 7.4.33, 8.0.30 and 8.1.34: in Plesk’s words, “Versions built on 21 October 2026 have fixes included.” Plesk for Windows now has fixed PHP 8.2, 8.3, 8.4 and 8.5, as 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The fix for sw-engine, the PHP that runs the Plesk panel itself, is still planned as hotfixes 18.0.80#11 and 18.0.81#4.

Wednesday, October 21: Google Cloud says customers must patch their own PHP

Google Cloud published its response to the two vulnerabilities, written by its CISO, Chris Betz, and Raluca Ada Popa of Google DeepMind. “While Google Cloud itself is not vulnerable, users of PHP running on Google Cloud may be vulnerable,” it says. App Engine standard on PHP 8.2 or newer is updated automatically, but App Engine flexible, Cloud Run and Cloud Run functions without automatic base image updates, and container images on GKE need rebuilding and redeploying. Marketplace solutions need an update from their provider, or a PHP update. “Container images you build yourself are your responsibility,” Google adds, and “Unsupported runtimes will not be patched.” If your WordPress site runs on Google Cloud from a Marketplace image or your own container, check who is updating its PHP.

Wednesday, October 21: Canada’s Cyber Centre publishes an advisory

The Canadian Centre for Cyber Security published advisory AV26-1070. It lists PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36 and 8.2 before 8.2.35 as affected, and encourages users and administrators to read php.net’s advisory and apply the updates. It names only the four supported branches, but older PHP is affected too: php.net’s advisories cover every version before the fixed ones. The Cyber Centre does not say whether the vulnerabilities are being exploited.

Wednesday, October 21: watchTowr says no attack has succeeded yet

watchTowr told SecurityWeek that its sensors picked up the first exploitation attempts around the time the fixes landed, but none had worked. “Whilst nobody has been successful to date, we don’t expect that will last long,” said Jake Knott, its head of threat intelligence. Other firms describe more. According to the same report, Hadrian said a few hours before the fixes, “We are now seeing php2shell exploited in the wild at scale,” mostly through the session upload progress route, and Vega saw attempts that used public proof-of-concept code. SecurityWeek’s report gives no numbers.

Wednesday, October 21: US agencies say update, or take systems offline

The NSA, the FBI and CISA all urged organisations to fix the two vulnerabilities, Nextgov reported, and warned that systems should be taken offline if they cannot be secured promptly. The NSA’s advisory says the vulnerabilities “often provide a direct path to the server’s file system or database”, recommends taking a system offline “until it can be fully mitigated” if an immediate update is not feasible, and says the NSA “will follow up shortly with more specific guidance.” CISA’s alert said that it had not observed exploitation of the vulnerabilities as of the time of publication.

Wednesday, October 21: Red Hat ships a fix for PHP 8.2 on RHEL 9

Red Hat published security advisory RHSA-2026:87072, rated Important, which fixes both vulnerabilities in the php:8.2 module stream on Red Hat Enterprise Linux 9, with the php package version 8.2.35-1. It covers RHEL 9 and its 9.8 Extended Update Support and Extended Life Cycle subscriptions. I have not yet seen Red Hat notices for its other PHP streams, or for RHEL 8 and 10.

Wednesday, October 21: the PHP Foundation explains how the embargo broke

The PHP Foundation published its account of the release. It says the out-of-memory problem first showed up while a core developer was fixing an issue from a 2024 external audit, and that the fix then stalled for months; in its words, “the delay was a structural failure.” Its timeline says the CVE numbers began circulating at about 11:00 am (15:00 UTC) on October 20, Calif mistakenly published a video of its proof of concept at about 4:00 pm (20:00 UTC), and Chainguard published built images containing the fix at 3:41 am (07:41 UTC) on October 21, more than six hours before the coordinated release. Proof-of-concept code spread quickly after the leak, but the Foundation says PHP’s security team “did not identify any functional exploits at the time of release/public disclosure.” It is changing how the security team decides, so a majority can settle a hard fix and leadership gets involved sooner when one stalls. Its advice: “If you run PHP, it is imperative that you update now.”

Wednesday, October 21: watchTowr now sees exploitation attempts

The security firm watchTowr, whose FAQ earlier in the day reported no attacks in the wild, published a new page on PHP2Shell saying it “is observing active exploitation attempts of both CVE-2026-109618 and CVE-2026-109619.” It gave no numbers or targets. It also warned that session upload progress “is not the only path to exploitation”, and that changes to .ini files “should be understood to be ineffective” as a way to stop attacks.

Wednesday, October 21: Ubuntu ships its fix

Ubuntu published security notice USN-8948-1, which fixes both vulnerabilities in its supported releases:

Ubuntu 24.04: php8.3 package version 8.3.6-0ubuntu0.24.04.13.
Ubuntu 22.04: php8.1 package version 8.1.2-1ubuntu2.28.
Ubuntu 26.04: php8.5 package version 8.5.4-0ubuntu1.5, and Ubuntu 26.10: 8.5.9-0ubuntu2.1.
Ubuntu 20.04, 18.04, 16.04 and 14.04: fixed through Ubuntu Pro in USN-8948-2.

Ubuntu’s blog post on the fixes says automatic security updates should install them within 24 hours, but whatever runs PHP still needs a restart, such as Apache for mod_php, or the server a reboot. Ubuntu’s per-CVE tracker pages still said “Needs evaluation” when I checked, but the two notices list the fixed packages.

Wednesday, October 21: Plesk ships fixed PHP for Linux servers

Plesk, a control panel many hosts use to run WordPress sites, updated its support article on the two vulnerabilities to say “Fixes for Plesk for Linux are already available” for its PHP 8.2, 8.3, 8.4 and 8.5 builds, as 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Its PHP 7.4, 8.0 and 8.1 builds “don’t have fixes yet”, and “Fixes for Plesk for Windows are not available yet.” Plesk’s own built-in PHP, sw-engine, which runs the control panel itself, is also affected; Plesk plans to fix it in hotfixes 18.0.80#11 and 18.0.81#4.

Wednesday, October 21: Debian ships its fix for Debian 13

Debian published security advisory DSA-6574-1, which fixes both vulnerabilities in Debian 13 (trixie) with the php8.4 package version 8.4.27-1~deb13u1. Debian 12 (bookworm) is not covered yet: Debian’s security tracker still lists its php8.2 package as vulnerable, with no fixed version.

Wednesday, October 21: OpenAI tells its side

OpenAI published a post on the coordinated disclosure. “To our knowledge, frontier AI found these vulnerabilities before attackers did,” it said, calling this “one of the most impactful security issues in recent memory.” It said the bugs are “among several significant vulnerabilities” it has found and is working to fix, that it is sharing a PHP version checker and a Codex skill to help find vulnerable versions, and that “For organizations using PHP, the priority now is applying the fixes.”

Wednesday, October 21, 10:00 am (14:00 UTC): the fix ships

php.net released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, saying they “fix two critical vulnerabilities that can allow unauthenticated remote code execution”, and published a security advisory. The main points:

Who is at risk: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” php.net considers the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”
CVE-2026-109618, “RCE via OOM corruption”: if PHP runs out of memory while it is still setting up a request, it can leave half-built data behind, and the clean-up step treats it as valid. Attackers can push PHP into that state with crafted multipart/form-data requests, the format browsers use for file uploads. php.net validated full remote code execution over HTTP against mod_php with default limits.
CVE-2026-109619, “RCE via stale global state”: some request data can survive after its memory has been freed, and the next request handled by the same PHP worker can use it. The confirmed routes run through session upload progress, which is on by default, and fatal error backtraces on PHP 8.5. A site does not need to use sessions for the upload progress route to work.
Older PHP: 8.1 and older get no official release, but “given the severity”, the security team published minimal source patches for PHP 7.4, 8.0 and 8.1 for people who build PHP themselves.
Packages: Linux distributions and long-term support vendors received the patches in advance. The volunteer-run Remi repository “will not have updates today”, and php.net urged its users to switch to distribution packages or build from source.
Stopgaps: php.net listed partial measures for people who cannot update at once, and was clear that they “do not make an installation safe”. They are covered in the “can’t update right away” section below.

Wednesday, October 21, 9:56 am (13:56 UTC): Cloudflare publishes the details

Minutes before the fix, Cloudflare explained what it had deployed and what it was seeing. It said it had “observed attack traffic targeting our customers”, and that attackers were changing their payloads to get around its rules. The main points:

Free plan: seven rules, “Generic Rules – Anomalous Execution” 1 to 7, in the Cloudflare Managed Free Ruleset. Free customers need to do nothing.
Pro, Business and Enterprise: the same seven rules in the Cloudflare Managed Ruleset. Cloudflare asks these customers to confirm the ruleset is deployed in block mode.
A second line of defence: a new rule for all plans, including Free, that checks what the server sends back and blocks a matching response before it reaches the attacker.
The limits: “Request data alone does not always provide enough evidence to distinguish an exploit from legitimate traffic,” Cloudflare wrote, and “Customers should patch their PHP repos even with WAF protections.” For managed hosting: “If a hosting provider manages PHP, ask the provider to apply the security update.”

Wednesday, October 21, 9:44 am (13:44 UTC): WordPress.org tells site owners to update PHP

WordPress.org published a post on WordPress News, written by John Blackbourn: “Due to the critical severity of the issues, site owners are encouraged to immediately update their installations of PHP.” It says the vulnerabilities “are not specific to WordPress” and that “No WordPress update is required or planned for these issues.” It asks site owners to check with their host, even though hosts may already be updating PHP or adding firewall rules, and says anyone running their own server on PHP older than 8.2 should consider taking it offline until PHP is upgraded, pointing to the same advice from the UK’s NCSC.

Wednesday morning: Cloudflare confirms early attacks

Cloudflare’s CTO, Dane Knecht, posted on X: “We are seeing early attacks emerging and are updating mitigations as new vectors show up.” He said “The rules are available to all customers, including free,” called them a stopgap, and told everyone to patch as soon as PHP released the update.

Wednesday, October 21, 3:34 am (07:34 UTC): first reports of attacks

Patchstack, a WordPress security company, updated its alert: “multiple active exploitation incidents confirmed.” Other firms, including watchTowr, had not yet confirmed attacks in the wild at that point. The UK’s NCSC told organisations to prepare for immediate PHP updates and to consider taking systems offline if they could not be protected.

Overnight: a workaround circulates, then gets walked back

Researchers reading PHP’s source code suggested turning off session upload progress, session.upload_progress.enabled, as a stopgap. By about 1:00 am (05:00 UTC), GMO Flatt Security, which had first suggested it might help, walked that back and warned that attacks bypassing it were expected. PHP core developer Gina Peter Banyard said: “the only mitigation is patching/upgrading PHP.” php.net later listed the setting as one of several partial measures; see the 10:00 am entry.

Tuesday, October 20, 11:02 pm (03:02 UTC on October 21): Cloudflare switches on protection

Cloudflare, which worked on the coordinated disclosure with the PHP Foundation, OpenAI, Wiz and others, says it turned on firewall protection automatically for customers on every plan from this time, hours before the fix shipped. Sites on its Free plan were covered without doing anything.

Tuesday, October 20: php.net moves the fix up a day

php.net posted an advance notice: “It is scheduled for Wednesday, 21 October 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.” It asked all PHP users to “prepare now”, and reserved the right to release earlier if details went public or attacks appeared. The same day, CERT-EU’s advisory 2026-018 told organisations to prepare to patch immediately and, where they could not, to consider isolating internet-facing applications.

Tuesday, October 20: the details leak

A post on Hacker News claimed two critical remote code execution vulnerabilities in PHP were about to be disclosed. It was deleted, but screenshots spread on X and Mastodon. The leak claimed a CVSS score of 10.0; PHP later rated each one 9.2. The security firm watchTowr confirmed the leaked information was real, adding: “We were all supposed to wait until Thursday at 11am ET.”

Before October 20: found by researchers, with help from AI

The vulnerabilities were found and reported privately. OpenAI later wrote that the security firm Calif found one of them using OpenAI’s GPT-5.6 Sol model, as part of OpenAI’s Patch the Planet initiative, and that the security firm Wiz found and reported both vulnerabilities independently. php.net’s two advisories (CVE-2026-109618, CVE-2026-109619) credit four reporters, and Cloudflare’s write-up also names Calif.io and Quarkslab as co-disclosers. The PHP team prepared the fix under embargo, with public disclosure planned for Thursday, October 22.

Is my WordPress site affected by PHP2Shell?

Yes, unless the PHP serving it is one of the fixed versions or a patched distribution build. WordPress shows you both things you need in one place: go to Tools, Site Health, Info tab, Server section.

PHP version is the PHP serving your pages, and the one that matters. php -v on the command line shows the CLI build, which can be a different installation.
PHP SAPI tells you how PHP runs. apache2handler means Apache with mod_php, the highest risk. fpm-fcgi means PHP-FPM, where php.net validated the CVE-2026-109619 session route. litespeed is LiteSpeed, which php.net also lists as at risk. Lower risk is not no risk; update all of them.

What does PHP2Shell mean for WordPress sites in particular?

It means the usual WordPress defences do not apply, because the vulnerable code sits underneath WordPress and the attack can fire before WordPress loads. Five things follow:

Updating WordPress, themes or plugins does not fix it. Patchstack says the vulnerabilities are “in the PHP interpreter, not in any one application.” Only a PHP update does.
Security plugins cannot block it. A WordPress firewall plugin is PHP code running inside the vulnerable interpreter, and php.net’s demonstrated exploit triggers before any application code runs. A security plugin can still help you spot a break-in afterwards.
Every WordPress site is reachable. The login page, comments, the REST API and admin-ajax.php all accept requests from anyone, and PHP handles every one of them. A maintenance-mode plugin does not help either: the request reaches PHP before the plugin’s code runs.
You cannot simply switch off uploads. The attack uses the same multipart/form-data format WordPress needs for the Media Library, the block editor’s uploads and any form with a file field.
Old PHP is common on WordPress sites. WordPress still runs on PHP 7.4, even though it recommends 8.3 or newer, so nothing in WordPress forces a site off an end-of-life version, and those versions get no official release.

This is not just theory for WordPress. Wiz, one of the teams that found the vulnerabilities, says it achieved remote code execution without logging in against the official WordPress Docker image, wordpress:latest, through each of the two vulnerabilities. It first confirmed this against WordPress on August 21, 2026, before reporting the vulnerabilities to PHP on August 24. Calif, another of the teams, lists WordPress 7.1.2 among the apps where it confirmed remote code execution without logging in, and says WordPress reaches the vulnerable code “through ordinary maybe_unserialize() calls”, the function WordPress uses to unpack stored options and metadata.

WordPress.org has now published its own guidance, and it matches php.net’s: update PHP now. It says “No WordPress update is required or planned for these issues,” so there is nothing to wait for from WordPress itself. It also asks you to check with your host, even if your host may already be updating PHP or adding firewall rules, and points to the same Site Health screen described above for checking your PHP version.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities, and they are on php.net’s downloads page. php.net’s advisories for CVE-2026-109618 and CVE-2026-109619 list every earlier version as affected.

PHP 8.5: update to 8.5.12 or later.
PHP 8.4: update to 8.4.27 or later.
PHP 8.3: update to 8.3.36 or later.
PHP 8.2: update to 8.2.35 or later. php.net reminds everyone that 8.2 reaches end of life on December 31, 2026, so plan the move to 8.3 or newer.
PHP 8.1, 8.0, 7.4 and older: no official release. See the section on old PHP below.

The version number is not always the whole story. Some distributions patch their own build without changing PHP’s version number. Ubuntu 24.04, for example, ships PHP as 8.3.6 and patches it by changing the package version, not PHP’s, so Site Health will still show 8.3.6 once Ubuntu’s fix is installed. Ubuntu has now shipped that fix in USN-8948-1: on Ubuntu 24.04, the fixed package version is 8.3.6-0ubuntu0.24.04.13, and the same notice covers Ubuntu 22.04, 26.04 and 26.10. Ubuntu 20.04 and older get the fix through Ubuntu Pro, in USN-8948-2. Debian has shipped its fixes for Debian 13, php8.4 package version 8.4.27-1~deb13u1 in DSA-6574-1, and for Debian 12, php8.2 package version 8.2.35-1~deb12u1 in DLA-4848-1. Red Hat has fixed the php:8.2 and php:8.3 module streams on RHEL 9, package versions 8.2.35-1 in RHSA-2026:87072 and 8.3.36-1 in RHSA-2026:87079, and the php:7.4 stream on RHEL 8, package version 7.4.33-8, in RHSA-2026:87080. On RHEL 10, Red Hat has fixed the php package, version 8.3.36-1.el10_2, in RHSA-2026:87070, and the php8.4 package, version 8.4.27-1.el10_2, in RHSA-2026:87071. SUSE has fixed SUSE Linux Enterprise Server 15 SP7, php8 package version 8.3.36-150700.3.24.1, and 15 SP6-LTSS, php8 package version 8.2.35-150600.3.39.1, according to its page for CVE-2026-109618, which also lists fixes for PHP 8.0 and 7.4 on its older long-term support releases. Amazon Linux has shipped fixes for its php8.2, php8.3, php8.4 and php8.5 packages on Amazon Linux 2023, package versions 8.2.35-1.amzn2023.0.1, 8.3.36-1.amzn2023.0.1, 8.4.27-1.amzn2023.0.1 and 8.5.12-1.amzn2023.0.1, in advisories ALAS2023-2026-3301 to ALAS2023-2026-3304. PHP 8.2 from the Amazon Linux 2 Extras is fixed too, in ALAS2PHP8.2-2026-015. On Amazon Linux 2023, install them with sudo dnf upgrade --releasever=latest, as Amazon’s documentation shows, because a plain dnf upgrade stays on the server’s current release. AlmaLinux has fixed every PHP stream on AlmaLinux 8, 9 and 10, keeping the PHP version number: on AlmaLinux 10, for example, the default PHP is fixed in package version php-8.3.33-1.el10_2.alma.1. If your PHP comes from a distribution, check its security notice for the two CVE numbers and compare package versions.

What should I do today?

Get a fixed PHP onto the server that serves your site, then confirm it from inside WordPress.

On managed WordPress hosting

Ask your host whether your server already runs PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched build, and if not, when it will. Name PHP2Shell and both CVE numbers. It worked if you get a time or a confirmation, not a general reassurance.
Switch to the fixed version in the hosting panel’s PHP setting if your host does not switch you automatically. It worked if Site Health, Info, Server shows the new number, or your host confirms the patched build.
Load the home page, log in and send a test form. It worked if nothing errors; a security release within the same branch should not change how your site behaves.

Some hosts have already answered the first question in public. Automattic says sites on WordPress.com, WordPress VIP, WP Cloud and Pressable are already protected, with nothing for customers to do. SiteGround says it rolled out server-level mitigation rules on all its servers before the fix was out. GoDaddy says it has patched all PHP versions on its Managed Hosting for WordPress and its Windows Hosting, and it is now deploying the fix to its Web Hosting servers, with mitigations in place until that finishes. OVHcloud says its shared hosting customers will get an updated PHP automatically, while customers on its VPS and Bare Metal servers have to update PHP themselves. Hostinger says its fix is now installed on every server except VPS, Kinsta says the PHP fix is now rolled out across its whole platform, and Bluehost says most of its servers are patched. Most of these posts do not say which PHP version your site runs now, so I’d still check Site Health, Info, Server when you can.

On your own server

Install the update from your distribution, following its security notice for CVE-2026-109618 and CVE-2026-109619, or build 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from source. It worked if the package version matches the notice, or php -v shows the fixed version.
Restart every PHP worker: PHP-FPM, Apache if you run mod_php, or LiteSpeed. Until then, the old code keeps serving requests. It worked if Site Health shows the new version, or the PHP-FPM processes started after the update.
Repeat for every PHP version and every site on the server, including old staging copies and test installs. It worked if each site’s Site Health shows a fixed build.

Three platform notes. If you install PHP from the Remi repository, switch to distribution packages or build from source, as php.net advises. If you run PHP in Docker, pull the new image, rebuild your own images with docker build --pull and recreate the containers. If you use a control panel such as cPanel or Plesk, its PHP builds follow the panel vendor’s schedule, so check their notice. For cPanel, cPanel’s release notes say EasyApache 4 25.91 fixes both vulnerabilities in its ea-php74 to ea-php85 packages, which covers PHP 7.4, 8.0 and 8.1 as well. If you run your own cPanel server, run the EasyApache 4 updates in WHM, then restart Apache and PHP-FPM. On Plesk for Linux, fixed builds of PHP 8.2 to 8.5 are out: install Plesk’s updates, then check Tools & Settings, PHP Settings, where each handler’s name shows its version. Plesk has also fixed its PHP 7.4, 8.0 and 8.1 builds for Linux, but they keep the same version numbers (7.4.33, 8.0.30 and 8.1.34), so check that the build date, which phpinfo() shows, is October 21, 2026, rather than the version. Plesk for Windows now has fixed builds of PHP 8.2 to 8.5. sw-engine, the PHP that runs the Plesk panel itself, is fixed in Plesk Obsidian 18.0.81 Update 4; on 18.0.80, the fix is still pending as Update 11. If your host runs Imunify360, CloudLinux says its WAF ruleset 8.83 blocks the shape of the public exploit on servers with the Imunify360 WAF switched on, as a stopgap and not a fix. On CloudLinux servers, fixed alt-php, ea-php and native PHP packages are now in CloudLinux’s stable repositories for every affected version: a regular package update installs them, while a security-only update may not see them until CloudLinux adds the advisory data. Fixed alt-php and ea-php packages keep a lower PHP version number, so check for the two CVE numbers with rpm -q --changelog rather than going by the version. Restart PHP afterwards.

What can I do if I can’t update PHP right away?

You can close some of the known attack paths, but nothing short of the update makes a site safe. In php.net’s words, these measures “reduce exposure to specific attack paths but do not make an installation safe.” watchTowr, which is now seeing exploitation attempts, goes further: it says changes to .ini files “should be understood to be ineffective” at stopping attacks. Most of php.net’s measures are server settings, so on managed hosting they are your host’s job; on your own server, they are yours.

For CVE-2026-109619, the stale state vulnerability:

Turn off session upload progress and restart every worker. It must go in php.ini, the PHP-FPM pool or the server configuration; php.net says not to rely on ini_set() or a PHP-FPM .user.ini file. This blocks the confirmed session routes, not every variant, and the advisory suggests leaving it off after patching if you don’t use it.
On PHP 8.5, also turn off fatal error backtraces and restart every worker. This blocks the confirmed backtrace route only.
Remove invalid or deprecated PHP settings applied per request, because they emit warnings before the request is set up, and php.net says hiding those warnings does not help. On WordPress sites, look for old php_value and php_flag lines in .htaccess left behind by past plugins or hosts.
Fix fatal errors and timeouts that visitors can trigger, such as a plugin’s upload or import that crashes. Your PHP error log, or wp-content/debug.log when WP_DEBUG_LOG is on, shows them.

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

For CVE-2026-109618, the out-of-memory vulnerability:

Set memory_limit to -1 in a way applications cannot override, such as php_admin_value in the PHP-FPM pool or Apache configuration. This removes the memory limit failure attackers can control, though php.net notes an underlying allocation failure can still reach the bug. WordPress will not lower it again: in WordPress 7.1.3’s code, both the startup memory setting and wp_raise_memory_limit() leave an unlimited limit alone. Pair it with a container or cgroup memory limit so one request cannot take the server down, and do not use RLIMIT_AS or RLIMIT_DATA, which php.net says can trigger the bug.
Lower post_max_size: 8M for sites that take no uploads, 32M if they do, with upload_max_filesize below it. Most WordPress sites take uploads, so 32M is the realistic number, and larger media uploads will fail until you patch. Site Health, Info, Server shows both values.
Enforce limits at the web server or proxy as well, on request size, number of input fields, multipart parts and headers, including requests that arrive without a usable Content-Length.

; PHP-FPM pool, for example /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_value[session.upload_progress.enabled] = 0

At the edge, in front of PHP:

If your site is behind Cloudflare, check the rules are working for you. On the Free plan they are on already and there is nothing to do. On Pro, Business and Enterprise, confirm the Cloudflare Managed Ruleset is deployed in block mode. Treat the rules as a stopgap, as Cloudflare does, and make sure nobody can reach your server directly and skip the CDN.
If you can restrict /wp-admin/ and the REST API to your own IP addresses at the CDN or web server, you can block multipart/form-data requests everywhere else on the site until you patch. Leave it alone if visitors upload files through a form.
When none of that is possible, take the site offline or put it behind access control at the web server or CDN, as CERT-EU, the NCSC and the US National Security Agency advise. Do the forgotten sites first: old staging copies, abandoned microsites and test installs on the same server.

What if my WordPress site is on PHP 8.1 or older?

Then you need to move to a supported branch, because PHP 8.1 and older get no official release from the PHP project. The source patches php.net published for 7.4, 8.0 and 8.1 are for people who build PHP themselves. Some Linux distributions and long-term support vendors backport fixes to older versions, so if your PHP comes from one, ask them. Ubuntu, for example, has fixed PHP 8.1 on Ubuntu 22.04, and PHP 7.4 on Ubuntu 20.04 for Ubuntu Pro subscribers. Red Hat has fixed PHP 7.4 on RHEL 8, Plesk has rebuilt its PHP 7.4, 8.0 and 8.1 for Linux servers with the fix, and CloudLinux now has fixed PHP packages in its stable repositories for every affected version, including 7.4, 8.0 and 8.1. SUSE lists fixed PHP 7.4 and 8.0 packages for its older SUSE Linux Enterprise Server 15 releases. AlmaLinux has patched its php:7.2, 7.3 and 8.0 streams on AlmaLinux 8 and php:8.1 on AlmaLinux 9, though it says future fixes for them are not guaranteed. cPanel has fixed its ea-php74 to ea-php85 packages in EasyApache 4 25.91, which covers PHP 7.4, 8.0 and 8.1 too. Not every vendor will, though: Amazon Linux lists its php8.1 package on Amazon Linux 2023 as “No Fix Planned”. For almost everyone else, the answer is a PHP version switch at your host.

WordPress recommends PHP 8.3 or newer, and I’d go there rather than 8.2, whose security support ends on December 31, 2026; 8.3 is supported until December 31, 2027. Test the switch on a staging copy first. If a plugin or theme breaks on 8.3, fix or replace it. The alternative is running a known remote code execution vulnerability that Amazon says is now being broadly exploited.

How do I check whether my WordPress site was already hit?

Look for PHP doing something a web server never should, and for files that should not exist. Huntress’s guidance points at PHP worker processes (php-fpm, php-cgi, apache2 or httpd) starting shells or tools such as sh, bash, curl, wget or nc. Then the usual WordPress checks:

New or changed PHP files in the web root, especially in wp-content/uploads, which should hold media, not PHP.
Administrator accounts you did not create, under Users.
Cron jobs you do not recognise, on the server and in WordPress.
Bursts of out-of-memory errors or PHP worker crashes in the error log around POST requests to pages that take no uploads. CVE-2026-109618 works by running PHP out of memory, so these are worth a closer look.
POST requests in your web server logs that contain PHP_SESSION_UPLOAD_PROGRESS, which Amazon suggests looking for.
Requests with the user agent php2shell-scan/109618, multipart boundaries containing ----p2s, or the text JACKALPOC, which ELLIO lists as signs of PHP2Shell scanning and exploit tools. Finding them means someone tried, not that they got in.

WP-CLI compares core and plugin files with the official copies and lists what differs:

wp core verify-checksums
wp plugin verify-checksums --all

If you find something, isolate the site, keep the web server and PHP logs, and restore from a clean backup after PHP is updated, not before, or the same door is still open.

Finding nothing does not rule out a leak. Wiz says attackers could also read sensitive data from PHP’s memory, “including passwords, tokens, and API keys”, without needing to run code on the server, and a leak like that leaves nothing for the file checks above to find. On a WordPress site, that memory holds the database password and the keys and salts from wp-config.php on every request. Amazon says to start investigations from October 17, when it saw the first attempt, so if your site was unpatched at any point since then, I’d change the database password, generate new salts (wp config shuffle-salts does it in one command), and replace API keys saved in plugin settings, such as SMTP, payment and backup services, once PHP is updated. New salts log everyone out, which is what you want.

The whole job today comes down to one line in Site Health: the PHP version, matched against 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package. On managed hosting, ask your host and check that line when they say it’s done. On your own server: update, restart every worker, check every site.