PHP Security Vulnerabilities CVE-2026-109618 and CVE-2026-109619 (php2shell): What InstaWP Customers Need to Know

What is php2shell?

php2shell is the informal name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. On 20 October 2026 the PHP security team gave advance notice of a security release scheduled for Wednesday 21 October 2026 at 14:00 UTC, fixing two vulnerabilities that are both rated CVSS v4.0 9.2 (critical).

PHP’s security advisory of 21 October 2026 describes two separate bugs. Both can allow remote code execution without a login:

• CVE-2026-109618 (out-of-memory corruption): when PHP runs out of memory, it can be interrupted while a request’s internal data is only partly set up. The cleanup step then treats that broken data as valid.
• CVE-2026-109619 (stale global state): internal data that belongs to one request can outlive the memory behind it, so a later request on the same PHP worker may use it before PHP resets it. PHP’s session upload-progress feature is one confirmed route to this bug, though not the only one.

In plain terms: an attacker who can reach a vulnerable site may be able to run their own code on the server. PHP says every PHP installation that serves web requests is at risk, whether it runs PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed. PHP rates the risk highest for mod_php, where it demonstrated an exploit in which an unauthenticated request triggers the attack before any application code runs.

PHP confirmed that all versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. PHP 8.1 and older are past end of life and get no official release. Because of the severity, the PHP security team published minimal source patches for PHP 7.4, 8.0 and 8.1 for people who build PHP themselves, and Linux distributions received the fixes in advance. Some Linux distributions and LTS vendors also ship backported fixes for PHP 8.1 and older. PHP 8.6.0 RC4, a test build released the same day, also contains the fixes. PHP says RC4 is not for production, and anyone testing an earlier PHP 8.6.0 build should move to it. The final release candidate, RC5, is planned for 5 November 2026. Security vendors report early exploitation attempts.

What has InstaWP done?

On the morning of 21 October 2026, InstaWP applied the recommended interim mitigation (disabling PHP’s session upload-progress feature) across all InstaWP-managed servers ahead of the release. We tested it on staging first and confirmed it caused no disruption to uploads or sites.

We installed the patched PHP versions on InstaWP-managed servers on 21 October, and the interim mitigation stays in place as extra protection. A small number of sites on older servers are being moved to upgraded servers; they keep the interim protection until then.

What do InstaWP customers need to do?

What you need to do depends only on the PHP version your site runs.

Sites on PHP 8.2 or newer

Nothing. Your site’s PHP has been patched. InstaWP installed the patched PHP versions on InstaWP-managed servers on 21 October, and the interim mitigation stays in place as extra protection.

Sites on PHP 8.1 or older

Your PHP version has been patched too. It’s end of life, so we still recommend moving to PHP 8.3 or newer when you can. PHP itself no longer supports 8.1 and older, and those versions won’t get future fixes. Test the change on a WordPress staging copy first, then make the same change on the live site:

1. Go to the Sites page in your InstaWP dashboard.
2. Click the ⋯ (horizontal ellipsis) button next to the site and select PHP Config.
3. Change the PHP version to 8.3 or newer and save.
4. Check the site’s key pages, forms and admin area before you repeat the change on production.

The full walkthrough is in the InstaWP guide to configuring PHP.

What should you do if you run PHP outside InstaWP?

Update PHP. PHP’s advice is to move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (source on the PHP downloads page), or to install your Linux distribution’s patched package. Windows source and binaries are on the same downloads page. On PHP 8.1 or older, ask your Linux distribution or LTS vendor whether it ships a backported fix, build from PHP’s source patches for 7.4, 8.0 and 8.1, or upgrade to a supported version. PHP says there is no complete mitigation and that updating is the only safe choice.

If you cannot update straight away, PHP’s advisory lists measures that cut off specific attack paths. They reduce exposure but do not make a server safe:

• Against CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then restart every worker. Setting it with ini_set() or an FPM .user.ini does not help. PHP notes this blocks the confirmed session paths but not other variants of the bug. On PHP 8.5, also set fatal_error_backtraces=0 and restart every worker, which blocks the confirmed fatal-backtrace path. Remove invalid or deprecated PHP settings applied per request that print warnings before PHP finishes starting the request (hiding the warnings with error_reporting, display_errors or @ does not help), and fix fatal errors and execution timeouts an attacker can trigger, including in callbacks, upload or import processing, and cleanup code.
• Against CVE-2026-109618: set memory_limit=-1 in a way applications can’t override (for example php_admin_value in the FPM pool), and lower post_max_size to 8M, or 32M if the site needs file uploads, keeping upload_max_filesize below it. PHP adds that memory_limit=-1 removes the controllable memory-limit failure, but a real allocation failure can still reach the bug. It also suggests enforcing limits at the web server or proxy on decoded request size, input field count, multipart part count, header count and nesting depth, including for requests without a usable Content-Length header.
• Use a container or cgroup memory limit as the availability boundary. PHP warns against using RLIMIT_AS or RLIMIT_DATA instead, because they can cause the very allocation failure the bug depends on.

These steps are for servers you manage yourself. On InstaWP-managed servers, InstaWP handles this for you, so you don’t need to change any PHP setting.

Timeline (UTC)

Newest first. New entries are added here as the situation develops.

Frequently asked questions

References

• PHP.net: Security advisory, critical remote code execution vulnerabilities (21 October 2026)
• PHP.net: Upcoming Critical PHP Security Release (20 October 2026)
• PHP.net: Supported versions and end-of-life dates
• InstaWP docs: Configure PHP for your site
• PHP security advisory for CVE-2026-109618
• PHP security advisory for CVE-2026-109619
• NVD: CVE-2026-109618
• NVD: CVE-2026-109619

Questions about your site? Contact InstaWP support and we will help.