PHP critical security update CVE-2026-109618: Versions and patch steps

The PHP critical security update CVE-2026-109618 was released on October 21, 2026, alongside a fix for CVE-2026-109619. Both flaws can allow unauthenticated remote code execution on affected PHP web servers. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install a vendor package containing the fixes.

The vulnerabilities affect PHP itself, so WordPress, Laravel, Drupal and other PHP applications may be exposed even when their application code is current. PHP rates both flaws critical, with a CVSS v4.0 score of 9.2.

Sansec and Tenable refer to the two vulnerabilities together as PHP2Shell. The name covers both CVEs and the exploit techniques associated with them.

PHP critical security update CVE-2026-109618: Which versions are fixed?

The PHP project published four security releases on October 21, 2026. Its official release archive and security advisory (opens in a new tab) confirm that each release fixes both vulnerabilities.

These version thresholds come from the PHP security advisories. A Linux distribution may retain an older upstream version number while adding security fixes to its own package. Check the vendor's patch information before deciding whether that package is vulnerable.

PHP 8.2 reaches end of life on December 31, 2026. Servers updated to 8.2.35 still need a migration plan.

Updating WordPress core, installing Laravel dependencies or updating Drupal modules does not replace this PHP runtime update.

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

Both vulnerabilities involve memory that PHP handles incorrectly when request processing ends abnormally.

CVE-2026-109618: Remote code execution through out-of-memory corruption

PHP uses a mechanism called longjmp() to leave certain operations when memory allocation fails.

The CVE-2026-109618 advisory (opens in a new tab) explains that PHP can encounter memory exhaustion while request data is partly initialized. The early exit leaves internal state invalid.

Request shutdown may then read or act on memory that was never properly initialized.

The researchers demonstrated that several memory exhaustion techniques can trigger the problem and lead to remote code execution.

The patch changes how PHP handles out-of-memory failures. It prevents the affected shutdown sequence from operating on invalid request state.

CVE-2026-109619: Remote code execution through stale global state

PHP workers can handle successive web requests. Some global state survives between requests, even though the memory referenced by that state belongs to an individual request.

The CVE-2026-109619 advisory (opens in a new tab) describes cases where fatal errors or cleanup operations leave references to freed memory.

A later request handled by the same worker may access those references before PHP resets them.

This is a use-after-free vulnerability. The confirmed impact includes memory disclosure and remote code execution with the PHP web worker's privileges.

The security patch resets affected state so it cannot be reused incorrectly across requests.

Both advisories assign a CVSS v4.0 score of 9.2. Exploitation requires no prior authentication or user interaction, although the underlying exploit conditions differ.

Which PHP servers are at risk?

PHP's security team identifies every PHP installation serving web requests as potentially affected when running vulnerable code.

The affected server interfaces include:

• PHP-FPM, commonly used behind nginx or Apache.
• Apache with mod_php, where PHP runs inside the Apache worker.
• php-cgi, the CGI interface for PHP.
• FrankenPHP, which embeds PHP into its server runtime.
• LiteSpeed, including PHP deployments using LSAPI.

The risk is highest for Apache mod_php.

The PHP advisory documents a working attack against mod_php where request processing reaches the vulnerable condition before application code executes. This means application-level authentication or request validation cannot intercept that particular path.

PHP-FPM behaves differently. When request startup fails, FPM terminates the affected child instead of continuing through the same shutdown path.

That difference does not make FPM safe. The stale-global-state advisory confirms an RCE path affecting FPM after successful request startup, when a suitable application operation and fatal interruption occur.

The advisories also identify potential paths involving FrankenPHP and LSAPI, with different levels of exploit validation.

For site owners, the practical distinction is simple: identify the PHP runtime serving the website and patch that runtime.

What happened between October 20 and October 21?

The coordinated security release followed an unusually compressed disclosure timeline.

PHP's original announcement did not provide the technical details. It gave users advance notice and warned that release timing could change if vulnerability information became public.

Patchstack's October 21 incident timeline (opens in a new tab) reports that hosting partners had already flagged exploitation incidents before the patches appeared.

Patchstack also recorded probing traffic shortly after the release, while saying its own telemetry did not yet provide firm evidence of breaches at that point.

Cloudflare introduced rules targeting known attack methods. These protections were described as temporary and do not replace the PHP updates.

How do you check the PHP version your server is running?

You need to check the PHP installation handling web requests. A server can have different PHP versions for command-line scripts and websites.

Check PHP from the command line

Open a terminal on the server and run:

php -v

The command prints the PHP version and identifies the command-line interface.

This confirms the PHP executable available through that shell. It does not prove that Apache, nginx or another web server uses the same PHP installation.

If the server hosts multiple applications or PHP runtimes, check each deployment separately.

Check PHP through the web server

PHP provides the phpinfo() function, which reports its runtime version, server information and configuration.

A temporary PHP file can contain:

<?php
phpinfo(INFO_GENERAL | INFO_CONFIGURATION);

Restrict access to the file before opening it through the web server. The output can expose system paths, configuration details and other sensitive information. Delete the file immediately after checking.

The PHP version at the top identifies the runtime that executed the request.

Also inspect the Server API field to determine whether the site uses FPM, an Apache module or another interface.

Check your hosting control panel

If you use managed or shared hosting, inspect the PHP version shown for the specific website or domain.

Confirm that the displayed version represents the active runtime rather than a version available for selection.

If the hosting panel does not show the complete patch number or vendor build, ask the provider to confirm whether both CVEs have been fixed.

Check production, staging environments, additional domains and PHP runtimes bundled into containers or other services.

How do you install the October 21 PHP security update?

Install the fixed release through the source that manages PHP on your server.

Linux distributions and managed servers

PHP says Linux distributions and long-term support vendors received the patches ahead of the public release.

Check your distribution's security updates and install its corrected PHP packages.

For a distribution-maintained build, the vendor's security advisory or package changelog matters more than the upstream version number alone.

After installing the update:

1. Restart or replace the PHP workers serving requests so they load the corrected build.
2. Restart any affected web server processes when required by the deployment.
3. Check the web-facing PHP version again.
4. Confirm both CVEs are covered by the installed build.
5. Test application routes, uploads, sessions and other critical operations.

A successful package installation does not prove every application has switched to the corrected runtime.

Source installations and Windows

The PHP project provides official downloads and installation information (opens in a new tab), including source releases and links to Windows builds.

Use the corrected release for your existing supported branch. Follow the relevant installation procedure for your platform.

For source installations, rebuild and deploy the patched PHP runtime. For Windows, obtain the corrected build appropriate to the existing server configuration.

Check the application after updating. Record the installed PHP version and deployment date so later investigations can establish when the fix became active.

Managed hosting

Ask your hosting provider to confirm the exact PHP build running the website and whether it includes both fixes.

If a patch is unavailable, request an immediate migration to a corrected PHP version or a suitable vendor backport.

A PHP application update or security plugin is not evidence that the underlying runtime has been repaired.

What if your server runs PHP 8.1 or older?

PHP 8.1 and earlier no longer receive ordinary upstream security releases from the PHP project.

The PHP team provided minimal source backports for three unsupported branches:

• PHP 7.4
• PHP 8.0
• PHP 8.1

The source-backport branches are linked from PHP's October 21 security advisory. They are intended for people compiling PHP themselves or operating without a long-term support vendor.

These backports do not restore normal maintenance or security support to the older branches.

For a production system, first check whether your Linux distribution or commercial support provider supplies a corrected package. Otherwise, plan a migration to a supported branch.

PHP also issued a specific warning about rpms.remirepo.net.

The project stated that this volunteer-maintained repository would not have updates on October 21. It urged users relying on it to move to distribution packages or compile PHP from source to obtain the fixes immediately.

Do not assume that a repository containing a newer-looking package has incorporated both security changes. Verify the package contents against its vendor's security information.

What can you change if PHP cannot be updated today?

PHP's security team published temporary configuration measures for installations that cannot be patched immediately.

These measures address particular exploitation methods. They do not provide complete protection against either vulnerability.

Reduce the CVE-2026-109618 memory exhaustion paths

The advisory recommends setting:

memory_limit = -1

This removes PHP's finite per-request memory limit, which the confirmed attack uses to trigger a predictable failure.

Apply the setting administratively where possible, such as through php_admin_value in an FPM pool or Apache configuration. Check that another configuration layer does not restore a finite value.

There is an important trade-off. Removing PHP's memory cap allows individual requests to consume more memory. An operating-system allocation failure can still trigger the vulnerable path.

PHP therefore recommends a container or cgroup memory boundary, ideally arranged so that only the affected worker is terminated.

The advisory warns against using RLIMIT_AS or RLIMIT_DATA as substitutes because they can cause memory allocation failures that reach the vulnerable code.

Reduce the maximum POST body size as well:

; If the application does not require uploads
post_max_size = 8M

For applications requiring file uploads, PHP suggests post_max_size = 32M instead.

Keep upload_max_filesize below post_max_size. These smaller limits can affect legitimate requests, so check the application's requirements.

PHP also recommends limits at the web server or proxy for decoded request size, multipart parts, field counts, headers and nesting. Such controls need to cover requests without a usable Content-Length.

Reduce the CVE-2026-109619 stale-state paths

Disable session upload progress:

session.upload_progress.enabled = 0

Apply this through php.ini, an FPM pool or server configuration that takes effect before request parsing.

Do not rely on ini_set() or FPM .user.ini for this mitigation. The vulnerable operations can run before those settings take effect.

Restart every PHP worker after making the change.

For PHP 8.5, also set:

fatal_error_backtraces = 0

This removes the fatal-error backtrace path used by a confirmed exploit. The directive was introduced in PHP 8.5, so this instruction applies specifically to that branch.

Finally, remove invalid or deprecated PHP settings that generate diagnostics during early request initialization.

Suppressing warning output with display_errors, error_reporting or @ does not stop the underlying vulnerable operation.

Review attacker-reachable fatal errors, including callbacks, uploads, imports, cleanup and execution timeouts.

These settings are temporary risk reductions. Install the complete PHP patches as soon as they are available, then reassess the temporary configuration changes.

What warning signs should you check in PHP logs?

The vulnerabilities operate inside PHP's request handling and memory management. An exploited application may not produce a useful application-level error.

During an isolated logging audit, enable log_errors=On, confirm that error_log works and set error_reporting=E_ALL in startup configuration.

The stale-global-state advisory recommends reviewing Apache, PHP-FPM, reverse proxy and service logs for:

• Repeated warnings or deprecations during request initialization.
• Fatal errors, parse failures and uncaught exceptions.
• Maximum execution time exceeded messages.
• Warnings during extension cleanup or request shutdown.
• Failures tied to attacker-controlled routes, content types or input.

Patchstack, citing Wiz Research, adds several indicators:

• Unusual multipart requests followed by memory errors or repeated HTTP 500 responses.
• Unexpectedly large or malformed PHPSESSID cookies.
• PHP workers restarting without an obvious operational cause.

These observations can indicate attempted exploitation, but none is proof that an attacker successfully executed code. Their absence also does not establish that a server was safe.

The PHP advisory warns that even an audit using E_ALL covers only the routes and application states exercised. Some failures may occur before PHP writes a log entry. An absence of errors in the logs is not proof of safety.

What should you do if the signs appear?

Preserve relevant logs and investigate the affected server as potentially compromised.

Check for unexpected changes to application files, executable content, scheduled tasks and server configuration. Review activity around suspicious requests and worker failures.

If compromise is suspected, isolate the affected service while preserving evidence. Check credentials and tokens accessible to the PHP worker and rotate those that may have been exposed.

Patch the runtime and investigate any unauthorized changes before returning the server to normal operation. Seek incident-response help if the available evidence cannot establish what happened.

Who discovered the two PHP vulnerabilities?

The GitHub advisories credit four reporting accounts:

• lcfr-hax
• sagitzadik-wiz
• tomash-areion
• amyb-oai

According to Sansec's PHP2Shell research report (opens in a new tab), the research involved Ryan Austin of Calif, Wiz Research and OpenAI. Sansec identifies the Wiz researchers as Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz.

The advisories also name arnaud-lb, iluuu1994, bukka and ndossche as remediation developers.

The reporting credits and technical details are recorded separately in the two official GitHub advisories linked above.

What should site owners check today?

Use this checklist to coordinate the update with your developer, system administrator or hosting provider.