What is the PHP2Shell vulnerability?
PHP2Shell is the name for two critical flaws in PHP, the language behind WordPress, Drupal, Joomla, Magento and Laravel. One crafted web request, sent without a username or password, can let an attacker run commands on the server as the account PHP runs under. It can also let them read the server's working memory, which can hold database passwords, session tokens, API keys and certificates.
CVE-2026-109618 is memory corruption in the way PHP handles running out of memory while it processes a request. CVE-2026-109619 is a use-after-free: state left behind by one request is reused by a later request on the same worker. The PHP security team rates both 9.2 under CVSS v4.0 and NVD rates both 9.8 under CVSS 3.1. Both are Critical, reachable over the network, with no authentication.
The PHP project published fixed releases on 21 October 2026 at 14:00 UTC, which was midnight on 22 October in Brisbane. The release came a day early after the CVE identifiers leaked on 20 October. The php.net announcement and the two GitHub security advisories, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, carry the technical detail.
Which PHP sites are exposed, and how do you check?
Every PHP installation that serves web requests is affected: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, on Linux and Windows. All supported PHP branches are affected, and older unsupported versions should be treated as vulnerable. ASD's ACSC states that all PHP versions from PHP 5 onwards may be affected. That includes PHP bundled inside container images, appliances and hosting control panels.
Apache with mod_php carries the highest risk, because an unauthenticated request can reach code execution before any application code runs. The PHP Foundation has also confirmed code execution on PHP-FPM through application code paths, so treat FPM sites as affected. Researchers demonstrated the attack against current WordPress, Drupal and Joomla installs. On a server you control, the check takes a few minutes.
- Run php -v on each server, then confirm the version each PHP-FPM pool or Apache module actually loads.
- Compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
- On Debian, Ubuntu or Red Hat packages, search the package changelog for CVE-2026-109618. Distribution backports keep the old version number.
- In cPanel, Plesk or another hosting panel, check the PHP version set for each site as well as the server default.
- List container images and appliances that ship PHP, and check each vendor's advisory.
- On shared or managed hosting, ask the provider which PHP build each site runs and when it was patched.
Which PHP version fixes PHP2Shell?
Update PHP to a fixed release, or install your distribution's patched package. Then rebuild every container image that includes PHP and restart every PHP worker, because a running process keeps the old code in memory. Patching is the only complete fix.
CISA and the UK NCSC advise taking PHP systems offline if they cannot be patched or mitigated quickly. CISA gives the same advice for any system on PHP 8.1 or earlier. PHP 8.2 reaches end of life on 31 December 2026, so a site patched to 8.2.35 needs an upgrade plan as well.
| PHP branch | Fixed release | Notes |
|---|---|---|
| 8.5 | 8.5.12 | On 8.5, also set fatal_error_backtraces=0 until the update is in |
| 8.4 | 8.4.27 | Official release |
| 8.3 | 8.3.36 | Official release |
| 8.2 | 8.2.35 | End of life 31 December 2026 |
| 8.1 and earlier | No official release | Source backports exist for 7.4, 8.0 and 8.1, and some distributions and LTS vendors ship patched packages. Plan the upgrade. |
Fixed releases published by the PHP project on 21 October 2026 at 14:00 UTC.
What can you do while a patch waits?
If the update has to wait for a change window or a hosting provider, these settings from the PHP advisories reduce the exposure. They are partial measures. Restart every PHP worker after each change, or it has no effect.
Web application firewall rules from Cloudflare and other providers also give partial protection. They do nothing for traffic that reaches the origin server directly, so the origin should accept web traffic only from the firewall.
- Set memory_limit=-1 administratively, in php.ini or the pool configuration, so applications cannot override it.
- Set post_max_size to 8M, or 32M where uploads are needed, and keep upload_max_filesize smaller than post_max_size.
- Set request size, field, part and header limits at the web server or proxy.
- Block multipart requests at the web server where the site does not use them.
- Set session.upload_progress.enabled=0 in php.ini or the pool configuration. ini_set and .user.ini do not apply it.
- Do not use RLIMIT_AS or RLIMIT_DATA limits as a workaround.
How do you tell whether someone already got in?
Several security vendors have recorded exploitation attempts, the earliest in a honeypot on 17 October. Neither CVE is in the CISA Known Exploited Vulnerabilities catalog as of its 21 October release. CISA had not observed exploitation when it published its alert, and ASD's ACSC is not aware of successful active exploitation within Australia. No public indicators of compromise exist yet.
Review web server and PHP logs from 17 October onwards for unusual uploads, odd session cookies and unexplained worker restarts. Proof-of-concept code circulating online is unverified and may carry malware, so do not run it to test a server. Clean application logs do not prove a server is safe.
- Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
- Oversized or malformed PHPSESSID cookies
- PHP worker restarts with no known cause
- Commands run by the web server account that it has no reason to run
- New or modified PHP files in the web root
How Black Shard fixes PHP2Shell
Black Shard runs the fix as one fixed-scope engagement, from finding every PHP runtime to confirming the patch held. Where there are signs of compromise, containment comes first and the work follows our incident response process.
The Essential Eight patch applications strategy sets a 48-hour window for internet-facing services when the vendor rates a flaw critical or a working exploit exists, and PHP2Shell is rated critical. A patched, verified and logged fix is evidence for that strategy in an Essential Eight assessment. Black Shard runs its own estate at Essential Eight Maturity Level Three.
- Exposure check: internet-facing hosts scanned from outside, and every PHP runtime, pool, container image and panel listed
- Patching: fixed releases or vendor packages installed, images rebuilt and every worker restarted in an agreed window
- Hardening: interim PHP and web server limits where a patch has to wait, and origins locked behind the firewall
- Verification: each host re-checked after the change, with version, package changelog and running workers recorded
- Log review: web and PHP logs from 17 October checked for the signs of exploitation
- Monitoring: scheduled external scans, so a new or forgotten PHP host is found and patched
How to engage Black Shard
Book a free 30-minute scoping call, or send a brief through the contact form or to info@blackshard.com.au naming the sites, servers and hosting providers involved. The call produces a fixed-scope quote covering the exposure check, patching, hardening, verification and log review, with scope and price agreed in writing before work starts.
If a server shows signs of compromise, call the 24/7 incident line on 1800 370 270. Treat the server as compromised and rotate every credential and key it held. Memory disclosure may expose personal information, so plan for an assessment under the Notifiable Data Breaches scheme, which Black Shard supports with a factual incident record. Report incidents to ASD's ACSC on 1300 CYBER1 (1300 292 371).
For sites that need a standing owner afterwards, attack surface management keeps internet-facing hosts on scheduled scans, and managed hosting runs applications on dedicated infrastructure that is patched, backed up, monitored and reported on every month.