PHP2Shell is a critical PHP security issue that can let an unauthenticated attacker run code on a vulnerable website server, according to the PHP security advisory of 21 October 2026. If your business uses WordPress or a custom PHP site, ask your host to confirm the patch running behind your domain now. The UK National Cyber Security Centre (NCSC) alert of 21 October 2026 calls for immediate action, and says to consider taking a system offline if the temporary mitigations cannot be applied or would take too long.
What happened with PHP2Shell?
On 21 October 2026, the PHP security advisory announced fixes for CVE-2026-109618 and CVE-2026-109619. Both can lead to remote code execution without a login. The flaws concern out-of-memory handling and internal request state that can survive after its memory has been freed.
PHP's memory-corruption advisory and stale-state advisory each assign a critical CVSS 4.0 severity score of 9.2. The PHP project identifies Apache mod_php as particularly exposed, with an attack path before application code starts.
On 26 October 2026, CISA announced that both CVEs had entered its Known Exploited Vulnerabilities catalogue. This confirms exploitation in the wild, but cannot identify which websites were attacked.
Is my PHP installation affected?
The PHP project's 21 October advisory covers installations serving web requests through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. WordPress and custom PHP sites are both worth checking.
Under that advisory, the 8.5 branch needs 8.5.12 or later; 8.4 needs 8.4.27 or later; 8.3 needs 8.3.36 or later; and 8.2 needs 8.2.35 or later. Earlier builds on each branch lack these two upstream fixes. A Linux vendor may instead supply a patched package without changing the displayed upstream version, so request its security notice and package build.
PHP 8.1 and older have no regular fixes from the PHP project, according to the same advisory. Exceptionally, PHP published minimal source backports for 7.4, 8.0 and 8.1; these do not restart support for those branches. If you are stuck there, obtain specific evidence of a vendor-maintained or source-applied fix while arranging a move to a supported release.
The PHP supported-versions schedule says security support for 8.2 ends on 31 December 2026. A site patched on that branch still needs a subsequent upgrade plan.
How to get an answer from your host
Check the PHP release shown for your domain in the hosting panel, if available. Treat it as a starting point: the panel default, a command-line version and the runtime serving visitors may differ. On a VPS or a site spread across pools, servers or containers, ask the administrator to identify every PHP instance serving public requests, including staging addresses.
Send this question: "Which effective PHP build serves requests for my domain on every web server, pool and container? Please confirm whether CVE-2026-109618 and CVE-2026-109619 are fixed, identify any vendor backport and its advisory, and confirm that old workers have been replaced. What evidence can you give me?"
Ask for a runtime check from the actual serving environment and a confirmation after deployment. Do not create a publicly accessible phpinfo() page to verify it; request a private administrator-side check. Test the working website yourself afterwards, particularly forms, bookings, checkout and login.
Contain exposure first, then finish the update
By 6 November 2026, the NCSC's emergency patch advice should be treated as an immediate containment task, not a routine job for the next maintenance slot. If your host cannot confirm protection, ask it to make sure no unpatched PHP can be reached from the internet, including through other hostnames and direct script addresses, while it prepares the update.
- Before changing PHP: Confirm an off-site files-and-database backup can be restored in an isolated environment and identify who can reverse a failed deployment without putting the vulnerable runtime back online.
- Deploy the fix: Have the administrator update every serving instance and restart services or replace all PHP workers as required. An installed package is insufficient if an old process is still serving requests.
- Check the result: Obtain evidence of the effective patched build on every pool, server and container. Test site functions and error logs; if compatibility fails, keep the public entry point isolated while restoring a safe copy or correcting the application.
The NCSC also calls for checking internal PHP installations and watching for vendor fixes in appliances or services that bundle PHP. Ask whoever manages your IT to include those, without delaying the public website's patch.
What if updating is not possible today?
The order is: the patched build; failing that, verified isolation; then the interim settings below; and escalation if none of these can be confirmed today. Ask for a written patch date and an administrator-led plan to reduce exposure in the meantime. CISA notes that a web application firewall may give some protection until systems are patched; treat it as an extra, never as the fix. The PHP security advisory explicitly says its configuration mitigations are incomplete. Do not change server memory limits yourself on shared hosting; if safe mitigation cannot be established promptly, ask the host to take vulnerable PHP offline.
For CVE-2026-109618, PHP proposes memory_limit=-1, set where applications cannot override it, such as php_admin_value in the FPM pool or Apache configuration, with a check that no pool, directory or application setting puts a finite limit back. This removes PHP's own memory ceiling, which can instead exhaust a worker or host. PHP recommends an independent container or cgroup memory boundary, ideally with recovery that kills only the affected worker; RLIMIT_AS and RLIMIT_DATA are specifically unsuitable because they can trigger the vulnerable allocation failure.
Only a server administrator should weigh that trade-off after checking resource isolation, backups and recovery access. They must restart every PHP worker so none keeps the old setting, verify the effective value across workers, monitor memory behaviour and keep a rollback plan. An underlying allocation failure can still reach the vulnerable path, so this is no clearance to leave a server exposed.
That advisory also suggests post_max_size = 8M where uploads are unnecessary, or post_max_size = 32M where required, with upload_max_filesize lower. PHP additionally calls for web-server or proxy limits on decoded request size, input fields, multipart parts, headers and nesting depth, including requests without usable Content-Length. Agree needed form sizes first and test submissions afterwards.
For CVE-2026-109619, PHP advises session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration effective before request parsing, followed by restarting every worker. Runtime ini_set() and FPM .user.ini are not suitable. The PHP stale-state advisory also recommends fatal_error_backtraces=0 on PHP 8.5 with worker restarts; administrators should remove invalid per-request settings causing diagnostics and fix reachable fatal errors and timeouts. Check the applied configuration, normal sessions and any upload progress bar the site uses afterwards. These measures block specified paths only.
A separate, rarer session issue
The PHP informational notice of 23 October 2026 identifies another possible remote-code-execution problem, CVE-2026-115560, which PHP calls unlikely in practice. It needs an application that sets session.serialize_handler to php_binary or php_serialize in its configuration, switches it to php with ini_set() before session_start(), and still has session upload progress enabled. PHP says applications that never change the handler at runtime can keep the feature on.
The PHP2Shell fixes issued on 21 October do not resolve this separate issue, according to that 23 October PHP notice. PHP suggests keeping session.upload_progress.enabled=0 until the next regular bug-fix release unless the application is known not to use the risky handler change. Ask the developer to check this condition and the effective setting; do not assume the earlier patch settled it.
If the site must close, protect visitors and search access
Google does not require a brief emergency closure to look like permanent deletion. For an urgent shutdown of one or two days, Google Search Central recommends an HTTP 503 Service Unavailable page. The maintenance response must come from a web server, proxy or separate static service that cannot execute vulnerable PHP scripts, including direct requests to other PHP paths.
Ask the administrator to serve lightweight static HTML with a realistic Retry-After header, as Google advises. Test the home page, important URLs and direct PHP paths from outside: closed pages should return 503 without executing PHP, while robots.txt should stay accessible with a normal 200 response and crawl-permitting rules, never 503. Do not use 403, 404, 410, 500, noindex or timeouts as substitutes.
If closure will last longer, Google recommends an indexable placeholder home page returning 200 instead of prolonged whole-site 503 responses. Serve it independently of the isolated PHP application and verify other vulnerable URLs remain inaccessible. Once patched, and once any sign of earlier compromise has been checked as the next section describes, remove the temporary routing, confirm real pages return 200 and retest functionality. The placeholder keeps the home page in search; other pages can still lose visibility during a long closure.
Could the website already have been compromised?
Yes. The CISA catalogue inclusion confirms exploitation in the wild, but does not prove an incident on your site. The NCSC advises looking for backdoors where an exposed system could not be secured promptly. Ask the host to preserve logs and investigate suspicious server behaviour before cleaning or restoring anything.
CISA's 21 October alert specifically advises monitoring PHP worker processes that start shells or download tools. Ask the host for those findings, for any exploit attempts in its web server or firewall logs while the server ran an unpatched build, and for the period covered. Those signs warrant escalation, but their absence does not establish that a server is clean. If an intrusion is plausible, bring in a qualified incident responder. If personal data may have been exposed, the ICO's breach reporting page explains whether to report it and what to do in the first 72 hours.
My view on ongoing website care
I would check the PHP version daily and keep it up to date. I see this as monthly website maintenance that a business can do itself or have somebody handle for it, including a security review once a month, as thorough as it can be. I would remove unused plugins and tools, keep strict rules on file uploads, make every allowed upload pass through a malware scanner with no bypass, so a flagged file never reaches the site, and disable uploads entirely unless the website needs them.
What to keep doing after patching
Keep the host's patch confirmation and check for further PHP security notices, especially the follow-up for the separate session issue. If your website accepts attachments, review its upload checks as well, including that a file the scanner flags or fails to scan is refused; they do not replace runtime updates or incident checks.
Get the patch answer today
Ask who is responsible for your live runtime and request evidence that every serving worker is patched. For future upkeep, monthly website care for WordPress and PHP sites describes the maintenance available. Keep any vulnerable service isolated until the PHP2Shell fix is confirmed.