PHP2Shell: How to Patch CVE-2026-109618 and CVE-2026-109619 in PHP, WordPress and Laravel

Security guide · WebmixStudio Editorial Team

Two critical PHP vulnerabilities disclosed on October 21, 2026, can allow unauthenticated remote code execution on affected PHP installations serving web requests. Tracked as CVE-2026-109618 and CVE-2026-109619, the pair has been referred to as PHP2Shell in security reporting. The PHP project has published patched releases and urges administrators to update immediately.

The essential point is simple: patch the PHP runtime that actually serves your website. Updating WordPress core, updating Laravel or running composer update does not patch the PHP interpreter. Those application and dependency updates remain important, but they are separate actions.

If you manage a production PHP website: identify the runtime and version serving live requests, apply the appropriate fixed release from PHP or your operating-system / hosting vendor, restart or redeploy the relevant services, and verify that the patched runtime is actually running. If you cannot patch immediately, reduce exposure under your vendor’s guidance; temporary controls are not a complete fix.

This guide explains the vulnerabilities at a high level, lists the fixed versions announced by PHP, and provides practical checks for WordPress, Laravel, shared hosting, virtual machines and container-based deployments.

PHP2Shell at a glance

• Disclosure and patch date: October 21, 2026.

• CVE identifiers: CVE-2026-109618 and CVE-2026-109619.

• Potential impact: unauthenticated remote code execution on a vulnerable PHP installation; the exact exposure depends on the runtime and configuration.

• Fixed upstream releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

• Potentially affected setups: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, plus products and containers that bundle PHP.

• Priority: patch internet-facing systems first, then verify workers, containers and less visible PHP deployments.

• Primary authority: PHP’s official security advisory.

The Canadian Centre for Cyber Security’s October 21 advisory reported open-source reporting of a proof of concept and said it had not identified active exploitation at the time of publication. That is a dated status statement, not a guarantee about the situation today. Treat current threat intelligence and subsequent vendor notices as authoritative as conditions change.

What is PHP2Shell?

PHP is a server-side language used by a wide range of sites and applications. WordPress and many Laravel applications run on PHP, as do other content-management systems, ecommerce platforms, APIs, business tools and custom web applications. A flaw in the PHP runtime can therefore affect more than one framework or product.

The name PHP2Shell is used in security reporting for these two vulnerabilities. It is a label for the vulnerability pair, not a separate PHP product or a WordPress plugin. The official PHP advisory describes the technical issues and affected serving configurations; it should be the first stop for patch status and version-specific guidance.

Both issues are serious because they involve PHP’s low-level request handling and memory state. In certain circumstances, a remote request may reach a vulnerable code path before normal application-level controls run. This is why validation rules, authentication middleware, WordPress plugins, Laravel policies or an application update cannot be treated as the fix for an interpreter flaw.

What do CVE-2026-109618 and CVE-2026-109619 mean?

The PHP project describes two distinct failure paths. The summary below is intentionally high-level; application owners should use the official advisory and linked security records for the authoritative technical details.

CVE-2026-109618: out-of-memory handling corruption

The PHP advisory describes an issue in which an out-of-memory condition can interrupt request processing while internal request data is only partially initialized. During cleanup, PHP may then treat invalid or incomplete internal data as valid. Under affected conditions, this can lead to remote code execution.

The practical lesson is not to try to reproduce the failure in production. It is to establish whether the PHP runtime is affected and patch it. Limits on incoming request sizes may reduce exposure to certain paths, but they are only part of a temporary mitigation plan and do not replace the fixed release.

CVE-2026-109619: stale internal request state

The second issue concerns request-owned internal state that may remain referenced after the memory backing it has been freed. A later request processed by the same worker may encounter that stale state before normal initialization has reset it. That can create another route to remote code execution in affected conditions.

Because a worker may serve multiple requests over its lifetime, teams should consider long-running workers, process restarts and the exact serving configuration when applying and verifying a patch. Restarting a process is not a substitute for installing a fix, but it can be an essential step after a properly patched runtime is deployed.

Why both issues require attention

Fixing only one symptom or relying on a network rule leaves the underlying runtime issue unresolved. The PHP project announced releases that address both vulnerabilities. Administrators should use a supported fixed release and confirm that the web-facing runtime, background workers and containers no longer run an affected build.

Which PHP versions are affected, and what should you install?

The PHP project published these fixed releases on October 21, 2026.

Do not install a release candidate in production just because it has a higher version number. Select a stable release supported by your host or distribution. Linux distributions and long-term-support vendors may supply backported fixes in their own packages, so the visible version string may not tell the whole story. Ask the vendor to confirm that the exact package installed on your system includes the fixes for both CVEs.

PHP 8.2 deserves special planning: its scheduled end-of-life date is December 31, 2026. Applying 8.2.35 addresses this security event for that branch, but it does not extend the branch’s normal support lifecycle. Plan an upgrade to a supported branch and test application compatibility before the deadline.

For the latest information, see the PHP 2026 news archive and advisory and the Canadian Centre for Cyber Security alert.

Which PHP server configurations should be checked?

The PHP project calls out installations serving web requests, including:

• PHP-FPM, including pools connected to Nginx or Apache;

• Apache using mod_php;

• php-cgi deployments;

• FrankenPHP;

• LiteSpeed;

• containers, hosted platforms, appliances and applications that bundle PHP.

The PHP advisory identifies mod_php as the highest-risk configuration among the listed serving methods because a demonstrated exploit can trigger the issue before application code runs. This does not mean other configurations are safe. Inventory every way a PHP runtime is exposed and confirm the patch status for each one.

A site may have more than one PHP runtime: one for web requests, another for command-line tasks, and additional versions inside containers, queue workers, cron jobs or staging systems. Fixing one runtime does not automatically fix the others.

What to do first: a practical response plan

1. Inventory public-facing systems

Start with websites, APIs, ecommerce stores, public upload forms and administrative panels that accept requests from the internet. Include production and staging environments, PHP-FPM pools, container images, scheduled tasks and long-running workers. Check third-party software and appliances that include PHP even if your team does not maintain their source code.

Keep a simple record with the hostname or application, owner, environment, PHP serving method, current package, patch source, target version, change time and validation result. The record makes it much harder for an old container or overlooked subdomain to remain exposed.

2. Confirm the actual runtime version

The command php -v reports the PHP command-line interpreter available in that shell. It may not be the PHP version used by a website. The web server could be using a separate PHP-FPM binary, a container image, a control-panel-managed package or a runtime maintained by the host.

Check the hosting panel, package manager or deployment configuration; identify the SAPI / serving method; and ask the provider to confirm which patched package handles live requests. Never leave a public phpinfo() page exposed as a convenient version check. If such a diagnostic page was created for a test, remove it once the check is complete.

3. Apply the fix from a trusted vendor

On a self-managed server, use the official PHP release or the package provided by your operating-system vendor. On managed hosting, use the provider’s supported process to change PHP versions or ask support to confirm the patched runtime. For older branches, request explicit confirmation of a backported fix rather than assuming that a version is patched.

Do not copy package-manager commands from another Linux distribution without checking your platform. Package names, repositories, service units and restart requirements vary. Record what changed and preserve a rollback path that does not reintroduce a vulnerable runtime.

4. Restart or redeploy the correct processes

After applying the fixed package, follow the vendor’s deployment instructions. Depending on the platform, the change may require restarting PHP-FPM, reloading or restarting the web-server integration, replacing container instances, or restarting queue workers. Existing processes may continue to run the previous interpreter until they are recycled.

Do not assume installation success proves remediation. Verify that the running web-serving process has loaded a fixed build and that scheduled jobs or long-running workers do not continue using an old container or executable.

5. Test the application and watch for regressions

Use a staging environment where practical. Test high-value paths such as login, account management, contact forms, file uploads, imports, checkout, API requests, scheduled tasks and background jobs. Review application logs, PHP error logs and service health after deployment.

If the app fails after the upgrade, troubleshoot compatibility with the new supported PHP version. Do not roll back to a vulnerable version and leave the application exposed without a risk decision, isolation plan and clear restoration deadline.

6. Review logs and indicators of compromise

Patching closes a known weakness; it does not prove that a system was never exploited. Because these flaws can have serious consequences, review relevant web-server, application, authentication and endpoint logs for unexpected activity around the period of exposure.

Investigate unexplained PHP worker crashes, unusual processes spawned by web services, unexpected files in web-accessible directories, new administrator accounts, unusual outbound connections or changes to scheduled tasks. These are general defensive checks rather than confirmed indicators unique to PHP2Shell. An absence of these signs is not proof that no compromise occurred.

If compromise is suspected, follow your incident-response procedure: isolate the affected system where appropriate, preserve logs and evidence, identify the initial access and persistence, rebuild from trusted sources when needed, rotate secrets from a clean environment, and restore only after addressing the underlying cause. Consult a qualified incident-response team for business-critical systems.

Temporary mitigations if an immediate patch is not possible

The PHP project states that updating is the complete solution. The measures below only reduce exposure to specific attack paths and do not make an installation safe. They should be implemented by a qualified administrator after reviewing the full official PHP advisory and the impact on the application. Do not paste configuration changes into production without understanding resource, upload and compatibility implications.

The PHP advisory describes several measures, including:

• For the out-of-memory path, specific controls around PHP memory-limit handling and request-size limits; applications that accept uploads may require different limits from applications that do not.

• Web-server or proxy controls for request-body size, multipart part counts and other parsing limits, including requests without a usable Content-Length.

• Container or cgroup limits designed to contain resource exhaustion without triggering the problematic failure mode; the advisory specifically cautions against substituting certain process memory limits.

• For the stale-state path, disabling session.upload_progress at the appropriate configuration level and restarting every relevant worker; the advisory notes that setting it from application code or .user.ini is not equivalent.

• On PHP 8.5, disabling fatal-error backtraces for the specifically confirmed path, along with reviewing diagnostic-producing invalid or deprecated per-request settings and attacker-reachable fatal errors/timeouts.

These controls are version- and environment-sensitive. Some may affect uploads, memory behavior, diagnostics or worker stability. Follow the authoritative advisory instead of treating this article as a configuration recipe. Do not represent a WAF, firewall, setting change or process restart as equivalent to the patched runtime.

If an internet-facing application cannot be patched in an acceptable time, the Canadian Centre for Cyber Security recommends considering isolation from public networks until a fix can be applied. The right response depends on business criticality, architecture and available controls; make it a documented incident decision rather than leaving the exposure unreviewed.

WordPress: what site owners need to do

WordPress websites may be exposed because WordPress executes on PHP. However, the official WordPress announcement states that this event concerns the PHP runtime, not a WordPress-core vulnerability; no WordPress update is required or planned specifically to fix these two PHP flaws. Updating WordPress alone will not patch PHP.

Use this sequence:

1. Check the PHP version. In WordPress, open Tools → Site Health → Info → Server. Hosting dashboards may provide the same information.

2. Confirm the web runtime. Ask whether the site uses PHP-FPM, mod_php or another serving method, and which patched package handles live requests.

3. Update PHP through the host. Apply the relevant stable fixed release or a confirmed vendor backport. Confirm that the change is active and all relevant workers are refreshed.

4. Update WordPress and extensions separately. Keep WordPress core, themes and plugins on supported releases; remove unused plugins and themes. These are important hygiene steps, but they are not the PHP2Shell fix.

5. Test site operations. Check admin login, page rendering, forms, uploads, search, ecommerce flows, scheduled actions and integrations.

6. Review administrative access. Check recent admin users, plugin/theme changes and file modifications if the site was exposed before patching.

For application development and maintenance support, see WebmixStudio’s custom WordPress development service. For ongoing protection processes and backup planning, explore security and backups and hosting and maintenance.

For the platform’s own explanation, read WordPress: Critical PHP Security Release.

Laravel: what application teams need to do

A Laravel application inherits the risks of the PHP interpreter that runs it. Updating the Laravel framework or a Composer package does not update PHP itself. Treat the runtime patch, dependency review and application regression test as separate tasks.

Check web traffic, workers and scheduled tasks

The php -v output from a deployment shell may not represent PHP-FPM or the container serving requests. Check the configured runtime for the web application, queue workers, Horizon or other long-running processes, and scheduled jobs. Separate deployments can have different images or packages, so confirm every environment independently.

Rebuild containers and deploy cleanly

If the application uses Docker, update the PHP base image to a fixed, supported version, rebuild the application image and deploy it through the usual pipeline. Check that old containers are replaced and that queue workers restart on the new image. Updating a Dockerfile in source control without building and deploying the new image does not remediate the running service.

Audit Composer dependencies independently

Run composer audit in the project workflow to identify known vulnerabilities in installed Composer dependencies. Review framework and library advisories and upgrade affected packages according to their maintainers’ recommendations. Remember that Composer audits do not patch PHP itself; both interpreter and package updates may be required.

Test the critical workflows

After the runtime is updated, test authentication, authorization, uploads, import/export jobs, queues, scheduled commands, webhooks, APIs, database operations and integrations. Review APP_DEBUG and other production settings, keep secrets out of source control, apply least privilege and maintain tested backups. These are defence-in-depth practices, not substitutes for patching PHP.

For application development or upgrade assistance, visit WebmixStudio’s Laravel/PHP development service. For deployment and patch-management discussions, see hosting and maintenance.

Shared hosting, cloud instances and containers

Managed or shared hosting

If you do not administer the server directly, contact the provider and ask concrete questions:

• Which PHP version and package serves this domain’s web requests?

• Has the vendor confirmed that the package includes fixes for both CVE-2026-109618 and CVE-2026-109619?

• When were PHP-FPM workers or equivalent services recycled after the fix?

• Are other domains, staging sites or scheduled jobs under the same account using a different runtime?

• Is there a supported migration path if the site uses PHP 8.1 or an older branch?

Keep the support confirmation and the date of the change in your maintenance record.

Virtual machines and dedicated servers

Map the exposed services first, then update using the server vendor’s normal package process. Validate all PHP pools and web-server integrations; do not assume that changing the default CLI package also updates an explicitly configured FPM service. After patching, test the application and verify process versions using vendor-supported methods.

Containers and orchestrated deployments

Track PHP in the image build, not only on the host machine. Rebuild image layers, scan or inspect the output where your process supports it, deploy updated images and confirm that all replicas and workers have rolled forward. Update base images used by jobs, scheduled tasks and internal services as well as the public web tier.

Vendor products and appliances

Some products bundle PHP internally. Ask the supplier for its security bulletin and fixed product version. Avoid manually replacing a bundled runtime unless the supplier explicitly supports that procedure; otherwise you can break the product or leave unsupported files behind.

Common mistakes to avoid

“WordPress is updated, so the problem is fixed.” Not necessarily. The vulnerability is in PHP. Verify the runtime separately.

“php -v shows a fixed version.” That only confirms the CLI executable you invoked. It does not automatically prove that PHP-FPM, Apache, a container or a different service is patched.

“The WAF blocks the request, so we can skip the update.” A WAF or firewall may reduce exposure to known patterns but cannot guarantee protection against every path. The PHP project states that the update is the complete solution.

“The provider updated one site, so the account is clean.” Other domains, worker pools, staging instances or containers may run different PHP packages. Check every environment and document the result.

“A successful patch means no one exploited the bug.” Patching prevents continued exposure to the known flaw but cannot rule out previous compromise. Assess the exposure window and investigate suspicious activity proportionately.

“The latest PHP branch is always the best change for production.” Use stable, supported releases and test compatibility. Do not deploy a release candidate as a production patch.

PHP security after the immediate patch

A critical advisory often exposes gaps in asset inventory and maintenance processes. Once the immediate issue is addressed, make these improvements part of normal operations:

• Maintain a record of PHP versions across production, staging, containers and third-party products.

• Subscribe to PHP, operating-system, hosting and framework security notices.

• Assign an owner and a target response time for critical vulnerabilities.

• Keep supported PHP branches in the upgrade plan and budget for end-of-life migrations.

• Test backups through restoration exercises, not only successful backup logs.

• Apply least-privilege access to files, services, database credentials and deployment accounts.

• Monitor server and application logs and retain enough history for investigation.

• Test major runtime upgrades in staging and preserve clear deployment and rollback procedures.

• Review plugin, theme and Composer dependencies separately from runtime patching.

The goal is to make the next vulnerability response predictable: know which systems are exposed, know who can change them, know how to verify remediation, and know what to do if a patch reveals evidence of compromise.

Frequently asked questions

Is PHP2Shell a WordPress vulnerability?

No. The two CVEs affect PHP itself. WordPress can run on an affected PHP runtime, but the WordPress project states that no WordPress-core update is specifically required for this event. Patch PHP through the hosting or infrastructure provider and keep WordPress updated separately.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

The releases announced by PHP are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For older branches, ask your distribution or long-term-support vendor whether it provides a backported fix, or plan to migrate to a supported branch.

Does Laravel need an update for PHP2Shell?

A Laravel application needs its PHP runtime checked and patched if it runs an affected version. Update Laravel and Composer dependencies according to their own advisories, but do not confuse those changes with a PHP interpreter update.

Can I use a WAF or firewall instead of patching?

No. These controls can help reduce exposure while remediation is arranged, but they are not a complete fix. Follow the PHP advisory and the guidance from your hosting or security vendor.

How can I tell which PHP version my WordPress site uses?

Open Tools → Site Health → Info → Server in the WordPress dashboard or check the hosting panel. Then confirm with the host which PHP package actually serves web requests; the CLI version may differ.

What if my server uses PHP 8.1 or older?

Those branches are outside the normal upstream support range. Some operating-system and long-term-support vendors may provide backports, and the PHP team has published limited source backports for some older versions. Contact your vendor and confirm the status of your exact build. If no supported fix is available, plan an urgent migration and consider isolating public access until remediation is possible.

Are temporary configuration mitigations enough?

No. The PHP project lists mitigations that can reduce exposure to specific paths, but it explicitly says those measures do not make the installation safe. Treat them as temporary, vendor-guided risk reduction while applying the fixed runtime.

How should a business respond if compromise is suspected?

Follow a documented incident-response process: isolate affected systems as appropriate, preserve logs and evidence, investigate persistence and data exposure, rotate credentials from a clean environment, and rebuild or restore from trusted sources where necessary. For critical systems, involve a qualified incident-response provider.

How WebmixStudio can help

PHP security is part of a broader website maintenance process: the runtime must be supported, deployments must be verifiable, backups must be restorable and application changes must be tested. WebmixStudio works across website development and maintenance, with relevant services for businesses reviewing PHP-based websites and applications.

• Security and backups: backup and security-maintenance planning.

• Hosting and maintenance: ongoing website maintenance and infrastructure care.

• Custom WordPress development: WordPress development and improvement work.

• Laravel/PHP development: custom PHP and Laravel application development.

For a project or maintenance discussion, book a call with WebmixStudio.

Official sources and further reading

1. PHP project — Security advisory: Critical remote code execution vulnerabilities, update now

2. PHP project — 2026 release archive

3. WordPress — Critical PHP Security Release, October 21, 2026

4. Canadian Centre for Cyber Security — CVE-2026-109618 and CVE-2026-109619, October 21, 2026

5. NHS England Digital — Critical Vulnerabilities in PHP (PHP2Shell)

This article is general security information and is not a substitute for vendor-specific instructions, a professional security assessment or incident-response advice. Fixed versions and temporary mitigations can change; check the official PHP advisory and your distribution or hosting vendor before making production changes.