Two unauthenticated remote code execution flaws in the PHP runtime itself, not in any one application. Fixed upstream in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Not in the CISA KEV catalog as of Oct 22. Cloudflare reported early attack attempts (via BleepingComputer); the PHP advisory makes no statement about exploitation in the wild.
The CVE records and GitHub advisories list PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. The PHP team's source backports for 7.4, 8.0 and 8.1 imply those branches are affected too; Wiz, one of the reporters, says versions back to 5.4 are affected. No official source names the earliest affected version.
Run one of these on your server or container and paste the output. Nothing leaves this page.
php -vphp-fpm8.3 -v # or php-fpm -vdpkg -l 'php*' | grep ^iiapk info -v | grep ^phprpm -qa 'php*'docker run --rm <your-image> php -vDistributions and hosting panels often backport the fix without changing the PHP version number, so compare your package version with the vendor's fixed build — not with php.net.
8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both CVEs. 7.4, 8.0 and 8.1 only have unreleased minimal source backports on php-src branches.
Check: php-fpm -v # or php -v; also check the SAPI that serves traffic
Official TS/NTS builds of 8.5.12, 8.4.27, 8.3.36 and 8.2.35 were published on Oct 21. The newest 8.1, 8.0 and 7.4 Windows builds predate the fix.
Check: php -v # for IIS FastCGI also run php-cgi.exe -v
All supported tags (8.2–8.5, latest; cli, apache, fpm, zts; Debian and Alpine) were rebuilt on Oct 21–22. The 8.1, 8.0 and 7.4 tags are end-of-life, are no longer rebuilt and stay vulnerable.
Check: docker pull php:8.4-fpm && docker run --rm php:8.4-fpm php -v # then rebuild images FROM it
trixie (DSA-6574-1) and bookworm LTS (DLA-4848-1) are fixed, plus sid. forky still has 8.4.26-1 until 8.4.27-1 migrates. bullseye and older get fixes only through Freexian's paid ELTS.
Check: dpkg -l 'php*' | grep ^ii
Rated Critical. Fixed in 26.10, 26.04 LTS, 24.04 LTS and 22.04 LTS (USN-8948-1); 20.04 and older through Ubuntu Pro (USN-8948-2). The version keeps the old upstream number.
Check: dpkg -l 'php*' | grep ^ii # on Pro systems: pro fix CVE-2026-109618
Errata shipped for RHEL 10, RHEL 9 (php 8.0, php:8.2, php:8.3) and RHEL 8 (php:7.4, php:8.2). The RHEL 9 php:8.4 module stream is affected with no fix yet. Red Hat rates the CVEs Important (CVSS 3.1 8.1).
Check: rpm -qa 'php*' ; dnf updateinfo list --cve CVE-2026-109618
AlmaLinux shipped its own patched builds for its PHP streams on 8, 9 and 10 (including retired ones) with an '.alma.1' suffix that keeps the old upstream version; the Red Hat rebuilds are available too. Rows below list the builds we verified.
Check: rpm -q php-common # compare the full version-release; php -v cannot show the backport
Rocky rebuilt six Red Hat errata on Oct 22 (Rocky 10, Rocky 9 php 8.0/8.2/8.3, Rocky 8 php:7.4). No advisory yet for Rocky 8 php:8.2; the EL9 php:8.4 stream has no fix upstream either.
Check: rpm -qa 'php*' ; dnf updateinfo list --cve CVE-2026-109618
No advisories. Stream 10 serves php 8.3.36-1.el10 and Stream 9 php 8.0.30-9.el9; Stream 10 php8.4 and the Stream 9 php:8.1/8.2/8.3 module builds are not updated on the mirror yet.
Check: rpm -qa 'php*'
Fedora 44 has php 8.5.12 in stable. Fedora 43's 8.4.27 update is still in updates-testing.
Check: rpm -q php-cli # F43: sudo dnf --enablerepo=updates-testing upgrade 'php*'
Amazon Linux 2023 fixed php8.2–8.5 (ALAS2023-2026-3301…3304) and AL2's PHP 8.2 extras topic. AL2023 php8.1 and AL2 core php are 'No Fix Planned'.
Check: rpm -qa 'php*'
Only SLES 15 SP7 (Web and Scripting module) has a released fix. SLES 16.0/16.1 are in progress, php7 packages and openSUSE Leap 16.x are listed as affected.
Check: rpm -q php8 ; zypper lp --cve=CVE-2026-109618
php83 8.3.36-r0, php84 8.4.27-r0 and php85 8.5.12-r0 are fixed on edge and v3.24. v3.23 has php83 only; php84 on v3.23 and php82–php84 on v3.21/v3.22 (outside community support) have no fix.
Check: apk info -v | grep ^php
Rebuilt packages on Oct 21: 8.2–8.5 carry the fixed upstream releases; the backport is verified in the 7.0, 7.4, 8.0 and 8.1 builds (their changelogs name both CVEs). Builds of 7.1–7.3 were not verified.
Check: apt-cache policy php8.3-cli # substitute your branch
EL 8/9/10 modules and SCLs carry 8.2.35, 8.3.36, 8.4.27 and 8.5.12 plus backports for 7.4, 8.0 and 8.1. The 5.6–7.3 builds do not mention these CVEs.
Check: rpm -qa 'php*' ; dnf module list --enabled php
Fixed builds for every PHP Plesk ships and for sw-engine. EOL 7.4/8.0/8.1 were rebuilt under the same version numbers: the build date must be Oct 21, 2026 or later. Plesk itself must be on 18.0.80 Update 11 or 18.0.81 Update 4.
Check: /opt/plesk/php/8.1/bin/php -v # build date must be Oct 21 2026 or later
EasyApache 4 25.91 moves ea-php82–85 to the fixed releases and backports the fix into ea-php74/80/81 without changing their versions; cPanel & WHM 136.0.50 updates cpanel-php84. Restart Apache/PHP-FPM after updating.
Check: rpm -q ea-php82 ea-php83 ea-php84 ea-php85 ; /usr/local/cpanel/cpanel -V
Fixed ea-php52–85 for CL7–CL10 and alt-php on CL7/8/9 (Oct 22), backported under lower version numbers. Native PHP packages are still rolling out. Run a full (not --security) update of 'alt-php*' and 'ea-php*'.
Check: rpm -q --changelog alt-php82-common | grep -E 'CVE-2026-(109618|109619)'
A new build moves CustomBuild PHP 8.2–8.5 to the fixed releases and patches 7.4/8.0/8.1 with unchanged versions. Run 'da update' then 'da build php'. Patches for 5.6–7.3 are still pending.
Check: da update && da build php ; php -v
The fix is your distribution's or sury.org's PHP packages plus a restart of every PHP-FPM service. ISPConfig offers a temporary 'ispconfig-multipart-guard' that blocks multipart requests (uploads break while active).
Check: php -v ; ispconfig-multipart-guard status
Virtualmin does not ship PHP: install your OS's (or PHP repository's) patched packages and restart PHP.
Check: dpkg -l 'php*' or rpm -qa 'php*'
AL2023 PHP platform 4.13.13 ships 8.5.12/8.4.27 (Oct 21) and 8.3.36/8.2.35 (Oct 22). 4.13.12 was only a partial mitigation. Without managed platform updates, update the platform version manually.
Check: Environment > Platform must be 'v4.13.13 running PHP 8.x'
Patched Bref 3 and Bref 2 layers and Docker images were published Oct 21. Run 'composer update bref/bref -W' (3.0.14 or 2.4.22) and redeploy. Bref 1 and PHP 8.1 or older are not rebuilt.
Check: aws lambda get-function-configuration --function-name <fn> --query Layers
Built-in Linux PHP images with the fixed releases are on the Latest and Standard channels; the Extended channel gets them last. Custom containers and EOL versions must be rebuilt by the customer.
Check: Kudu WebSSH: php --version
Standard PHP 8.2+ runtimes are patched automatically. PHP 8.1 or older is not patched; App Engine flexible and custom runtimes must be redeployed on a patched PHP.
Check: Confirm the configured runtime is PHP 8.2+; redeploy flexible apps
PHP 8.2+ services are patched automatically only with automatic base image updates enabled; otherwise rebuild with a patched PHP and redeploy.
Check: docker run --rm YOUR_IMAGE php -v
Buildpack v298 adds 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and rebuilds 8.1.34 on Heroku-22 with the EOL backport. Redeploy your apps to pick them up.
Check: heroku run php -v # 8.1.34 needs a redeploy on or after Oct 21
Every running app was patched in place to 8.5.12/8.4.27/8.3.36/8.2.35; no action required.
Check: Optional: php -v from an app command
Patched native PHP 8.2+ runtimes are live: redeploy. Docker-image runtimes need a new deployment. PHP 8.0/8.1 have no patch.
Check: Redeploy, then php -v in a Vapor command
Patched PHP 8.2–8.5 images on all regions by Oct 21, Dedicated clusters by Oct 22; 7.4 images rolled out. No action required; 7.3 and older are not patched.
Check: php -v in the app container
Automatic security updates do not patch PHP: click 'Update PHP X.X' for every installed version (or follow the SSH guide), then restart queue workers, Horizon and Octane. PHP 8.0/8.1 have no patch; Ubuntu 20.04 servers should be replaced.
Check: php8.4 -v && php-fpm8.4 -v # for each installed version
Live sites and paid pre-production environments are patched (8.2–8.5 and LTS 5.6–8.1 builds). Free and sandbox environments follow within 24–48 hours. No action required.
Check: No action required
Patched PHP 7.4–8.5 across the platform; incident resolved Oct 22 08:26 UTC. No action required.
Check: WordPress Tools > Site Health > Info > Server
Status incident (Oct 21) says the fix is being deployed to all PHP versions with protections in place meanwhile; no completion update found yet.
Check: WordPress Tools > Site Health > Info > Server
Autonomous is fully patched; Flexible servers are being patched (most done by Oct 22 morning UTC) with mitigations and WAF rules meanwhile. No action required.
Check: status.cloudways.com
All shared, cloud and cPanel hosting servers have patched PHP 5.2–8.5. VPS customers manage PHP themselves and must update and restart it.
Check: hPanel > PHP Configuration ; on VPS: php -v
Managed WordPress and Windows Hosting are patched; Web Hosting (cPanel) is still being deployed with mitigations. VPS customers must update PHP themselves.
Check: WordPress Tools > Site Health > Info > Server
Before the release SiteGround deployed server-level mitigations and disabled the affected functionality; no post-release confirmation of patched builds found yet.
Check: Site Tools > PHP version
No WordPress release is needed: update PHP. Self-hosted sites on PHP older than 8.2 should consider going offline while upgrading.
Check: Tools > Site Health > Info > Server
PSA-2026-10-20: no core release is involved; updating PHP is the only complete mitigation.
Check: Reports > Status report
Operators must move to fixed PHP; Nextcloud All-in-One v14.4.1 ships it.
Check: docker exec -it nextcloud-aio-nextcloud php -v
No vendor statement found yet. Independent researchers confirmed the issue is reachable on Magento: update PHP on every web node.
Check: php -v on every web node
Managed rules (including the Free Managed Ruleset) block known attack patterns since Oct 21. Origins reachable directly bypass the WAF; patching PHP is still required.
Check: Paid plans: Cloudflare Managed Ruleset deployed in block mode
Core rule set SizeRestrictions_BODY for CVE-2026-109618 and PHP Managed Rule Group 2.3 for CVE-2026-109619. AWS: upgrading PHP is the only complete fix.
Check: WebACL uses SizeRestrictions_BODY and PHP rule group 2.3
Managed rule 99006001 is rolling out (completion expected Oct 28) and is disabled by default; enable it. Upgrading PHP is the only full fix.
Check: Enable rule 99006001 (MS-ThreatIntel-Response-CVEs)
Google recommends managed rules (File Upload and RFI categories) plus a rule rejecting bodies over inspection limits. Not a replacement for patching.
Check: Review Cloud Armor preview/enforcement decisions in Cloud Logging
Rulesets 8.83–8.85 block the public exploit pattern for CVE-2026-109619 only; nothing covers CVE-2026-109618. Only the PHP update closes the flaws.
Check: imunify360-agent update --force modsec-rules
Virtual-patching rules for known PHP2Shell paths; can miss variants and are bypassed if the origin is reachable directly. Install patched PHP and restart workers.
Check: Block direct origin access; verify the PHP version served
No firewall rule: some attack paths run before WordPress loads, so the application firewall cannot be relied on. Install patched PHP and restart it.
Check: WordPress Tools > Site Health > Info > Server
Set memory_limit=-1 where applications cannot override it (php_admin_value in the FPM pool or Apache config).
CVE-2026-109618 · Not a complete mitigation: an underlying allocation failure can still reach the vulnerable path. Restart all workers. source
Lower post_max_size (8M without uploads, 32M with uploads) and keep upload_max_filesize below it; enforce request-size, field-count and multipart limits at the web server or proxy.
CVE-2026-109618 · Reduces exposure only. The limits must also cover requests without a usable Content-Length. source
Set session.upload_progress.enabled=0 in php.ini or the FPM pool (not ini_set() or .user.ini) and restart every worker.
CVE-2026-109619 · Blocks the confirmed session paths, not other variants. source
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
CVE-2026-109619 · Blocks the confirmed fatal-backtrace path only. source
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, 2026. Distribution and hosting-panel packages may carry the fix under a different version number, so compare against your vendor's fixed build.
Not necessarily. Debian, Ubuntu, RHEL and some hosting panels backport the fix without changing the upstream version string. Compare your package version with your vendor's row on this page. For php.net builds and the official Docker images, an older version means you are not patched.
Officially the CVEs list 8.2–8.5, but the PHP team published source backports for 7.4, 8.0 and 8.1, which implies they are affected. These branches have no official release: rely on a vendor backport, apply the interim mitigations and upgrade.
The advisory scopes the risk to installations serving web requests (FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed). Patch the binary that serves traffic — check it with php-fpm -v or a phpinfo() page, not only php -v.
No. The PHP team says the measures reduce exposure to specific attack paths but do not make an installation safe; updating is the only complete fix.
Pull the php base image again, rebuild every image built from it and redeploy. Supported tags (8.2–8.5) were rebuilt on October 21–22; the 8.1, 8.0 and 7.4 tags are no longer rebuilt and stay vulnerable.
Security releases and breaking changes in one weekly email, or instantly on Telegram.
The vendor table is available as JSON (CC BY 4.0). Use it in scripts, dashboards or CI checks.
curl https://www.changes.watch/api/v1/advisories/php2shellFound an outdated status? Tell us via contact — every row links to the vendor's own advisory.