PHP Fixes Two Critical Remote Code Execution Flaws. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 Now

TL;DR: PHP has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, which fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that PHP says “can allow unauthenticated remote code execution.” Every version below those four on the supported 8.2 to 8.5 branches is affected. PHP says “all PHP installations serving web requests” are at risk and calls updating “the only safe choice.” If you run a WordPress site or any other PHP app, check your PHP version now and update it, or ask your host when it will. AWS now says PHP2Shell “is now seeing broad exploitation attempts in the wild.” Updating isn’t the whole fix anymore: a separate PHP bug, CVE-2026-115560, has no fix yet, and PHP suggests setting session.upload_progress.enabled=0 until its next regular bugfix release (see the Oct 24 update). CISA added both PHP2Shell flaws to its Known Exploited Vulnerabilities catalog on October 26 (see the Oct 27 update). CISA now also says a Linux kernel flaw, CVE-2026-46300, can be chained with PHP2Shell to run commands as root, so update and reboot the kernel on servers you manage (see the Oct 29 update).

Update, Oct 29, 2026, 7:40 p.m. Manila: Palo Alto firewalls are being attacked. Palo Alto Networks says attackers are exploiting PHP2Shell against PAN-OS firewalls and Panorama whose management interface is exposed to the internet. PAN-OS uses PHP in its admin web interface, so the fix there is a PAN-OS hotfix from Palo Alto, not a PHP update you install yourself. See our PAN-OS story for the fixed versions and steps.

Update, Oct 29, 2026, 9:05 a.m. Manila: patch the Linux kernel too. On October 28, CISA added a Linux kernel flaw, CVE-2026-46300, to its KEV catalog. CISA’s entry says it “can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root,” so on an unpatched Linux server, a PHP2Shell break-in can become full control of the machine. CISA gave US federal civilian agencies until October 31 to fix it. The kernel CVE isn’t new: NVD published it on May 23, 2026, and lists these stable kernels as the first fixed versions: 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10. NVD lists every kernel from 3.9 up to and including 5.10.257 as affected, including the 4.19, 5.4 and 5.10 series, with no fixed version older than 5.15.208. If you run PHP on your own Linux server or VPS, install your distribution’s latest kernel update and reboot, because a new kernel only takes effect after a restart. On shared or managed hosting, the host runs the kernel, so ask it to confirm it’s patched. Updating PHP is still the first step.

Update, Oct 27, 2026, 11:47 a.m. Manila: CISA now lists PHP2Shell as exploited. The US Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on October 26, and gave US federal civilian agencies until October 29 to fix or mitigate them. Both entries list known use in ransomware campaigns as “Unknown.” CISA also updated its October 21 alert to note the KEV listing. The alert urges organizations to update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 immediately, and says those that can’t, or that still run PHP 8.1 or earlier, “should take PHP-based systems offline until they can be patched or updated.” The deadline only binds US federal civilian agencies, but KEV is a useful priority list for everyone: if you haven’t updated yet, do it now, then follow the Oct 24 advice on session.upload_progress.enabled.

Update, Oct 24, 2026, 7:00 a.m. Manila: a new, unpatched PHP bug means updating isn’t the whole fix. On October 23, PHP posted an informational advisory about a separate bug in its session upload progress feature, CVE-2026-115560. PHP suggests setting session.upload_progress.enabled=0 “until the next regular bugfix release, to fully protect from an unlikely RCE vector.” It says the bug needs an app that sets session.serialize_handler to php_binary or php_serialize in its configuration and then switches it to php at runtime with ini_set() before calling session_start(), with upload progress still enabled; apps that never change the serialize handler at runtime can keep the feature on. There’s no fixed version yet: PHP says it is handling the bug in its regular release cycle and will publish a full advisory with the next release. Cloudflare updated its php2shell post (last modified Oct 23, 11:09 p.m. Manila) to say the bug “affects fully patched PHP releases, including 8.5.12, and will be fixed in PHP’s next regular release.” Cloudflare says its WAF protects all its WAF customers against known exploit attempts if their site uses PHP’s default upload progress field name, but not if they’ve changed session.upload_progress.name. Updating to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 still fixes PHP2Shell, so do that first. Because the new bug affects those fully patched versions, also set session.upload_progress.enabled=0 unless you’re sure none of your apps switch the serializer at runtime. It’s the same setting PHP listed as a stopgap for CVE-2026-109619; PHP says that if you applied it then, “keep it in place and no further action is needed.”

Update (Oct 21, 10:07 p.m. Manila): PHP published the fixed releases and its security advisory on October 21, ahead of the 14:00 UTC schedule; the two GitHub security advisories are timestamped 13:34 UTC (9:34 p.m. Manila). We’ve added the affected and fixed versions, the CVE IDs, PHP’s guidance on what to do if you can’t update yet, and CERT-EU’s advisory. We’ve also rewritten the headline and summary and replaced our pre-release preparation steps with what to do now. The rest of this story, first published at 8 a.m. Manila before the release, is below.

Update (Oct 22, 9:18 a.m. Manila): attacks seen, and what Cloudflare and Google Cloud customers get. Cloudflare, which calls the pair “php2shell,” says the vulnerability “was leaked before the official release date and we observed attack traffic targeting our customers,” with attackers changing their payloads to try to get past its rules. Its WAF protections have been on by default since 3:02 UTC on October 21 (11:02 a.m. Manila) for every plan with the WAF deployed, including Free: Free sites need no action, while Pro, Business and Enterprise customers should confirm the Cloudflare Managed Ruleset is deployed in block mode. Cloudflare says to patch anyway. Google Cloud says App Engine standard apps on PHP 8.2 or newer are updated automatically, and Cloud Run services and Cloud Run functions are updated automatically only if automatic base image updates are on. App Engine flexible apps, containers you build yourself and GKE workloads must be rebuilt or redeployed; Google Cloud Marketplace solutions that include PHP, such as a content management system or LAMP stack, need the update from the solution provider or a direct PHP update; and apps on PHP 8.1 or older must move to 8.2 or newer. It also lists Cloud Armor managed rules as a stopgap, now recommended in enforce mode (see the Oct 23 update). Both companies’ posts say the flaws reach back to PHP 5.4. If your site sits behind a WAF, keep it on, but treat it as extra cover, not a fix.

Update (Oct 22, 10:20 p.m. Manila): AWS says attacks started four days early and exploitation attempts are now widespread. Amazon Threat Intelligence says its MadPot honeypots logged a PHP2Shell exploitation attempt on October 17, four days before the fixes, from an IP address tied to a commercial anonymization network. AWS says it’s “unclear how the actor acquired exploit information prior to disclosure,” and that it’s unclear whether that or the later attempts it saw on October 21 (from about 02:00 to 08:00 UTC, 10 a.m. to 4 p.m. Manila, with payloads that suggest multiple actors) would have worked on real systems. After the fixes came out, it says, new proof-of-concept exploits appeared within hours and PHP2Shell “is now seeing broad exploitation attempts in the wild.” AWS advises starting any investigation from the earliest known exploitation, “at least starting on October 17th,” not from the disclosure date. Its security bulletin says AWS services themselves aren’t affected, but customers running PHP on them may be: Elastic Beanstalk has updated PHP platform versions, and environments without Managed Platform Updates must be updated by hand; Amazon Linux has updated PHP packages; and Lightsail instances can’t be updated in place, so you need to create new instances from updated blueprints and migrate. AWS WAF’s PHP managed rule group is being continuously updated for both CVEs, and the default version protects you automatically, and AWS says upgrading PHP is “the only complete fix.”

Update (Oct 23, 7:30 a.m. Manila): Docker has patched its PHP images. Docker says its Docker Official Images for PHP have been updated on Docker Hub and mirrored to Amazon ECR, and its Docker Hardened Images now ship PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, released within 24 hours of PHP’s fixes. Docker advises customers using these images to update immediately. Pulling the new image isn’t enough on its own: rebuild any image built FROM a PHP base image and redeploy the containers, because running containers keep the old PHP until they’re replaced. Docker repeats that upgrading PHP is the only complete fix, and says that if you can’t update right away, you should take the system offline until you can.

Correction, Oct 23, 2026, 10:40 a.m. Manila: AWS has changed its wording since our last update; it now says PHP2Shell “is now seeing broad exploitation attempts in the wild,” and we’ve updated the quote.

Update, Oct 23, 2026, 10:40 a.m. Manila: AWS and Google Cloud revise their guidance. AWS says its WAF PHP managed rule group is being continuously updated for both CVEs and protects customers on the default version automatically; if you pin a version, move to the latest. Elastic Beanstalk now has PHP 8.2 to 8.5 platform versions with the fix; Lambda has no managed PHP runtime, so update and redeploy custom runtimes and container images; Lightsail blueprints are available in all regions. Google Cloud now recommends its stable Cloud Armor rules in enforce mode, calls Cloud Armor a compensating control rather than a fix, and says Security Command Center’s External Exposure service can scan for exposed PHP workloads on Compute Engine, GKE and Cloud Run.

What changed

According to PHP’s October 21 security advisory and its two GitHub security advisories:

• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The GitHub advisories list every version before those as affected on each branch.
• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption”: if PHP runs out of memory while some request data is only partly set up, the cleanup at the end of the request can treat that broken data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state”: some internal state from one request can outlive the memory it points to, and a later request on the same worker can use it before it is reset.
• Who is at risk: PHP names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs.”
• Severity: PHP rated both flaws CVSS v4.0 9.2 in its advance notice, and the GitHub advisories mark both as critical.
• Linux packages: PHP says Linux distributions and LTS vendors got the patches in advance, so check your vendor for updated packages. It says the volunteer-run rpms.remirepo.net repository “will not have updates today.”
• Old branches: PHP 8.1 and older don’t get updates from the PHP project. Because of the severity, PHP’s security team published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source or have no LTS vendor.
• If you can’t update yet: PHP lists stopgaps that “reduce exposure to specific attack paths but do not make an installation safe.” For CVE-2026-109618, they include setting memory_limit=-1, preferably in a way apps can’t override, a low post_max_size, and request-size limits at the web server or proxy. For CVE-2026-109619, they include setting session.upload_progress.enabled=0 in php.ini or the FPM pool, not with ini_set() or .user.ini, and restarting every worker. The advisory has the full list and caveats.

CERT-EU, the cybersecurity service for EU institutions, published advisory 2026-018 before the release; its page dates the advisory October 20, 2026, 20:33, without naming a time zone. It advised organisations to prepare for immediate patching and, where that isn’t possible, to consider isolating internet-facing applications from public networks until a fix is applied.

What to do now

1. Check your PHP version. In WordPress, go to Tools > Site Health > Info and open the Server section. On a server you manage, run php -v.
2. If your host manages PHP, ask when it will patch. On shared or managed hosting, your host updates PHP. Check its status page or open a ticket tonight and ask for the fixed version on your branch.
3. If you patch yourself, update now. Install your distribution’s updated package or build the fixed version for your branch, then restart PHP-FPM, Apache or whatever runs PHP so every worker picks it up. For containers, pull the updated base image and rebuild.
4. Then turn off session upload progress. Updating fixes PHP2Shell, but not CVE-2026-115560, a separate bug that affects fully patched PHP and has no fix yet. PHP suggests setting session.upload_progress.enabled=0 until its next regular bugfix release. If you already set it as a PHP2Shell stopgap, keep it in place. PHP says apps that never change the session serialize handler at runtime can keep the feature on, so skip this only if you’re sure of that for every app on the server.
5. If you’re on PHP 8.1 or older, plan the move. Ask your vendor about a backport, or upgrade to a supported branch. Until then, apply PHP’s stopgaps and treat them as temporary.
6. Don’t trust unofficial details. Use php.net and the official advisories for versions and fixes, not posts that claim exploit details.
7. Update the Linux kernel too. If you manage the server, install your distribution’s latest kernel update and reboot. CISA says Linux kernel flaw CVE-2026-46300 can be chained with PHP2Shell to run commands as root (see the Oct 29 update).
8. Check for signs of compromise from October 17 on. Because AWS saw exploitation attempts before the fixes, review web server and PHP logs, new or changed files in your web root, new admin accounts and unexpected outbound connections from October 17 onward, not just since the patch. If you find anything, treat the server as compromised and rotate the keys and passwords it holds.

What happened before the release

PHP posted the advance notice on php.net on October 20, and Jakub Zelenka sent it to the php.announce mailing list at 19:33 UTC that day (October 21, 3:33 a.m. Manila). According to PHP:

• When: the release was “scheduled for Wednesday, 21 October 2026 at 14:00 UTC.”
• What: it “addresses two critical vulnerabilities, both rated CVSS v4.0 9.2.”
• What wasn’t public yet: “Full details, affected versions, and the fixed versions will be published with the release.”
• It could come sooner: PHP says, “We reserve the right to release earlier should details of either vulnerability become public, or should evidence of active exploitation appear in the wild.”
• What PHP asks: “All PHP users are encouraged to prepare now so they can upgrade as soon as the release is available.”

When we first checked, on the morning of October 21, PHP’s releases list still showed 8.5.11, 8.4.26, 8.3.35 and 8.2.34, all from September 24, as the newest versions.

Who should care

Every WordPress site runs on PHP, including WooCommerce stores, and so do many other websites and web apps. WordPress recommends that hosts support “PHP version 8.3 or greater.”

PHP’s supported-versions page lists four branches that still get security fixes: 8.2 (until December 31, 2026), 8.3 (until December 31, 2027), 8.4 (until December 31, 2028) and 8.5 (until December 31, 2029). If your site runs PHP 8.1 or older, that branch isn’t on PHP’s supported list, which is why this release only covers it with source backports.

If you’re updating servers today anyway, also see our story on eight compromised eMudhra certificate keys, which also asks you to update and rebuild server images.

What we’ll watch

We’ll update this story if PHP changes its advisories or adds fixed versions, including the fix and full advisory for CVE-2026-115560, or if major vendors report new exploitation details, or if CISA changes its KEV listing.

Updates

• Oct 29, 2026, 7:40 p.m. Manila: Palo Alto says PHP2Shell is being exploited against PAN-OS management interfaces exposed to the internet; added a note linking to our PAN-OS story.
• Oct 29, 2026, 9:05 a.m. Manila: CISA added Linux kernel flaw CVE-2026-46300 to KEV on Oct 28 and says it can be chained with the two PHP2Shell flaws to run commands as root; added NVD’s fixed kernel versions and a step to update and reboot the kernel.
• Oct 27, 2026: CISA added both CVEs to its Known Exploited Vulnerabilities catalog on Oct 26; US federal civilian agencies must fix or mitigate them by Oct 29.

Sources & method

Sources

• PHP security advisory, “Critical remote code execution vulnerabilities, update now,” Oct 21, 2026
• CISA Known Exploited Vulnerabilities catalog, CVE-2026-109618 and CVE-2026-109619, added Oct 26, 2026
• CISA KEV catalog data feed (JSON)
• CISA KEV catalog, CVE-2026-46300 (Linux kernel), added Oct 28, 2026, catalog version 2026.10.28
• NVD, CVE-2026-46300
• Palo Alto Networks security advisory CVE-2026-109618, PHP vulnerabilities in Palo Alto Networks products (updated Oct 29, 2026)
• CISA alert, “Critical Vulnerabilities in PHP Require Immediate Patching,” Oct 21, 2026, last revised Oct 26, 2026
• CISA Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk,” June 10, 2026
• PHP news archive, “Informational advisory: Session upload progress” (CVE-2026-115560), Oct 23, 2026
• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements, Oct 21, 2026
• GitHub security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618), php/php-src
• GitHub security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), php/php-src
• PHP 8 ChangeLog
• CERT-EU security advisory 2026-018, “Critical Vulnerabilities in PHP”
• Cloudflare, “Cloudflare deploys protections against php2shell vulnerability,” Oct 21, 2026, updated Oct 23, 2026, 11:09 p.m. Manila
• Google Cloud, “Responding to core PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619,” Oct 21, 2026, updated Oct 21, 3:30 and 4:25 p.m. PDT, and Oct 22, 9:25 a.m. and 4:07 p.m. PDT
• AWS Security Blog, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot,” CJ Moses, Oct 21, 2026
• Docker, “Security Update on PHP2Shell: Impact for Docker Customers,” Oct 22, 2026
• AWS security bulletin 2026-143-AWS, “PHP web runtimes (CVE-2026-109618 and CVE-2026-109619),” published Oct 21, 2026, 2:30 p.m. PDT, last updated Oct 22, 2026, 2:00 p.m. PDT
• PHP news archive, “Upcoming Critical PHP Security Release,” Oct 20, 2026
• php.announce message 509, “Upcoming Critical PHP Security Release,” Jakub Zelenka, Oct 20, 2026
• PHP supported versions
• PHP releases list (JSON)
• WordPress requirements
• WordPress documentation, Site Health screen

Method. First checked October 21, 2026, at 7:40 a.m. Manila time; last checked October 29, 2026, at about 7:00 p.m. Manila time (11:00 UTC). The Palo Alto details in the 7:40 p.m. October 29 update come from Palo Alto’s security advisory, checked October 29 at about 7:00 p.m. Manila time (11:00 UTC). The Linux kernel details in the October 29 update come from CISA’s KEV catalog entry for CVE-2026-46300 (catalog version 2026.10.28) and its NVD record. The fixed versions, CVE IDs, affected setups and stopgaps come from PHP’s security advisory, release announcements and GitHub advisories; the affected version ranges and advisory times come from the GitHub advisories. The schedule and the 9.2 score come from PHP’s October 20 announcement. CERT-EU’s guidance comes from its advisory. The attack traffic, WAF rules and platform patching details in the October 22 update come from Cloudflare’s and Google Cloud’s own posts. The exploitation timeline and AWS platform details in the 10:20 p.m. update come from AWS’s blog post and security bulletin. The Docker image details in the October 23 update come from Docker’s post; the advice to rebuild and redeploy is our own. The CVE-2026-115560 details in the October 24 update come from PHP’s October 23 informational advisory and Cloudflare’s update to its post; the advice to keep both the update and the setting is our own. The KEV dates, the federal civilian agency deadline and the ransomware field in the October 27 update come from CISA’s KEV catalog and its data feed (catalog version 2026.10.26); which agencies the deadline binds comes from CISA’s Binding Operational Directive 26-04; the alert details come from CISA’s October 21 alert, last revised October 26. Support dates come from PHP’s supported-versions page. The steps under “What to do now” are our own judgment. No affiliate links on this page. How we work.