PHP2Shell: Patch CVE-2026-109618 and CVE-2026-109619 in PHP

A developer-focused guide to fixed releases, runtime verification, WordPress and Laravel deployments, containers, workers, and post-patch checks.

Action required: PHP announced security releases on October 21, 2026, fixing two critical vulnerabilities that can allow unauthenticated remote code execution on affected systems. Inventory your PHP runtimes, patch the runtime that serves requests, restart or redeploy the relevant processes, and verify the result. The PHP project says there are no complete mitigations; updating is the only safe choice.

Official starting point: PHP security advisory.

What is PHP2Shell?

The name PHP2Shell has been used in security reporting for two PHP runtime vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project disclosed the issues on October 21, 2026, alongside fixed releases.

The vulnerabilities are in PHP itself, not only in a particular framework or CMS. That distinction matters because WordPress, Laravel, ecommerce platforms, APIs, and custom applications all depend on the runtime that executes their PHP code.

The PHP advisory identifies installations serving web requests as in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP considers the risk highest for mod_php, where a demonstrated exploit can trigger the vulnerable path before application code runs.

The Canadian Centre for Cyber Security reported on October 21 that open-source reporting indicated a proof of concept was available, with no active exploitation identified at the time of its alert. That status is time-bound; consult current vendor and threat-intelligence updates rather than treating it as a guarantee.

Sources: PHP project · Canadian Centre for Cyber Security

The two vulnerabilities, at a high level

The PHP advisory describes two different failure paths:

• CVE-2026-109618 — out-of-memory handling: An out-of-memory condition can interrupt request processing while internal request data is only partially initialized. Cleanup may then treat invalid data as valid.
• CVE-2026-109619 — stale request state: Internal state owned by a request can remain referenced after its backing memory has been freed. A later request handled by the same worker may encounter the stale state before normal initialization resets it.

These summaries are deliberately high-level. For technical details and the authoritative description, use the official PHP advisory.

The operational lesson is that application-level validation, authentication middleware, WordPress plugins, Laravel policies, and dependency updates cannot be relied on to fix a flaw in the PHP interpreter itself.

Which PHP versions fix the issue?

The PHP project announced these fixed releases on October 21, 2026:

Branch	Fixed release
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35

Update to the appropriate fixed release or a later supported security release for your branch. Use packages from PHP or your operating-system / hosting vendor.

PHP 8.1 and older no longer receive routine security updates from the PHP project. Some distributions and long-term-support vendors may backport fixes. Ask the vendor to confirm that the exact package in your environment addresses both CVEs; do not assume a package is vulnerable or fixed based on a version string alone when the vendor backports patches.

If you're on an older unsupported branch and cannot confirm a vendor fix, plan a migration to a supported branch. Consider isolating internet-facing applications from public access until remediation is possible, based on your risk assessment and vendor guidance.

A runtime patch is not a framework update

A key source of confusion is the difference between the PHP interpreter and the application running on it.

• composer update changes Composer-managed dependencies; it does not patch the PHP binary.
• Updating Laravel does not automatically replace the server's PHP runtime.
• Updating WordPress core does not patch PHP.
• Updating a Dockerfile does not change containers already running until a new image is built and deployed.
• Updating a host's CLI PHP package does not prove that PHP-FPM or another web-serving runtime has been updated.

WordPress confirmed that these vulnerabilities affect PHP applications generally and that no WordPress-core update is specifically required to fix them. WordPress site owners must confirm their PHP runtime is updated through their host or infrastructure team.

Reference: WordPress — Critical PHP Security Release.

Step-by-step remediation for developers and operators

1. Inventory every PHP runtime

Start with internet-facing applications, then include staging, internal tools, scheduled jobs, queue workers, containers, and vendor products that bundle PHP.

Capture at least:

• Application or hostname and environment
• PHP version and serving method
• Package repository, hosting provider, or container image
• Owner responsible for the change
• Patch status and verification evidence

One machine may have more than one PHP version or execution path. A list of domains alone is not enough if they use different FPM pools, containers, or runtimes.

2. Verify the runtime that serves requests

php -v reports the command-line interpreter invoked by the current shell. It may not match the PHP-FPM binary, Apache module, managed-hosting runtime, or container that serves live traffic.

Check the web server or FPM configuration, hosting dashboard, package manager, deployment manifest, or container image. In managed hosting, ask the provider to confirm the package serving the domain and whether the patch for both CVEs is installed.

Avoid exposing a public phpinfo() page for diagnostics. If you create a temporary diagnostic, restrict access and remove it immediately after use.

3. Patch through a supported channel

On a self-managed host, install the supported patched package for your distribution and branch. On managed hosting, follow the provider's update path and request confirmation for the exact runtime.

For containerized applications, update the PHP base image to a fixed supported version, rebuild the image, deploy the replacement, and check that old containers are gone. A source-control change alone does not remediate a running deployment.

For vendor appliances or products that bundle PHP, use the vendor's security advisory and supported patch procedure. Manually replacing a bundled interpreter can break the product or leave unsupported files behind.

4. Restart or redeploy the right processes

Depending on the platform, the deployment may require recycling PHP-FPM workers, restarting relevant services, replacing containers, or restarting long-running queue workers and scheduled processes. Follow the system vendor's instructions.

Don't assume the package installation itself proves that every active process is now running the patched runtime. Verify after the deployment.

5. Test the application

Run smoke tests for important user and business workflows. For example:

• Login and account management
• Upload and import flows
• Forms and API endpoints
• Checkout and payment callbacks, if applicable
• Queue jobs and scheduled commands
• Database access and third-party integrations

Watch application logs and service health after the update. Resolve compatibility issues without casually rolling the production application back to a vulnerable runtime.

6. Look for signs of compromise

Patching prevents continued exposure to the known flaw; it does not establish that the system was never compromised.

Review relevant web-server, application, authentication, and endpoint logs for suspicious behavior during the exposure window. Investigate unexpected files, accounts, processes, commands, or outbound connections associated with PHP or web-server services. These are general defensive checks, not indicators unique to PHP2Shell.

If compromise is suspected, follow your incident-response process: contain the affected system where appropriate, preserve evidence, investigate persistence and scope, rotate potentially exposed credentials from a clean environment, and restore services only after addressing the cause. Bring in a qualified incident-response team for critical systems.

WordPress-specific checks

WordPress site owners can check the PHP version reported by WordPress under Tools → Site Health → Info → Server. Also check the hosting panel and ask the host which runtime serves web requests.

Then:

1. Have the host or infrastructure team apply the PHP fix.
2. Confirm that relevant workers and services use the updated runtime.
3. Update WordPress core, themes, and plugins separately as normal maintenance.
4. Test logins, uploads, forms, search, checkout, and key integrations.
5. Review administrator accounts and unexpected file or plugin changes if the site was exposed before patching.

WordPress/plugin security tools are useful parts of defense in depth, but they do not replace the PHP runtime patch.

For WordPress development support, WebmixStudio provides custom WordPress development. For maintenance planning, see security and backups.

Laravel and custom PHP checks

Laravel inherits the risk of the runtime it uses. Updating framework dependencies should be handled separately from updating PHP.

• Check PHP-FPM or the actual web runtime, not only the CLI binary.
• Update container images, rebuild, deploy, and replace old replicas and workers.
• Use composer audit to review known Composer package advisories, while remembering that it does not patch the PHP interpreter.
• Test queue workers, scheduled jobs, uploads, webhooks, APIs, authentication, database operations, and integrations.
• Keep production debugging disabled and protect application secrets as part of broader hardening.

For Laravel/PHP application work, see WebmixStudio's Laravel/PHP development service. For deployment and ongoing upkeep, see hosting and maintenance.

What about temporary mitigations?

The PHP project states that there are no complete mitigations; updating is the only safe choice. Some controls may reduce exposure to particular paths in specific versions or configurations, but they should not be described as making an affected runtime safe.

If an immediate patch is not feasible, review the official advisory with your PHP / hosting vendor and consider isolating the internet-facing application until it can be fixed. Do not blindly copy configuration snippets from a post into production: resource limits, request parsing and diagnostic settings may vary by PHP version and application requirements.

Official reference: PHP security advisory.

Common mistakes to avoid

“WordPress is updated, so we're safe.” Not necessarily. Confirm the PHP runtime separately.

“php -v is patched, so the website is patched.” Not necessarily. The CLI runtime can differ from PHP-FPM, Apache, or a container.

“The WAF blocks requests, so we can skip the PHP update.” No. A WAF is not a substitute for the fixed release.

“We updated the Dockerfile.” That does not replace the running image until the image is rebuilt and deployed.

“Patch success proves we weren't compromised.” It doesn't. Consider the exposure window and review logs where appropriate.

Turn this incident into a repeatable process

After remediation, improve the process that will help you respond to the next critical advisory:

• Keep a current inventory of PHP runtimes, containers, apps, and owners.
• Subscribe to PHP, operating-system, hosting, and framework security notices.
• Define who can approve and deploy emergency changes.
• Plan branch upgrades before end of life.
• Test backups by restoring them, not just by checking that backup jobs ran.
• Maintain logs and a documented escalation process.
• Verify every production patch and record the outcome.

Security work is not finished when a website launches. Runtime lifecycle, deployment quality, monitoring, and recovery are part of operating a reliable web application.

How WebmixStudio can help

WebmixStudio works across website development and maintenance. If you're reviewing a PHP-based application, these services may be relevant:

• Security and backups
• Hosting and maintenance
• Custom WordPress development
• Laravel/PHP development

For the full website version of this guide, see the WebmixStudio PHP2Shell patch guide. You can also book a call with WebmixStudio to discuss a project or maintenance requirement.

Official references

1. PHP — Security advisory: Critical remote code execution vulnerabilities
2. WordPress — Critical PHP Security Release, October 21, 2026
3. Canadian Centre for Cyber Security — CVE-2026-109618 and CVE-2026-109619

Security guidance can change. Verify current instructions from PHP and your operating-system, hosting, or product vendor before making production changes. This article is general information, not a substitute for vendor-specific advice or incident-response support.