Skip to content

Critical PHP vulnerabilities

PHP has released fixes for two critical remote code execution vulnerabilities. This post sets out what PHP has confirmed and what to do now.

Swarm Intelligence banner with redacted text

Two critical PHP flaws can let an attacker run code on your servers, or read data from server memory, without logging in. PHP has released fixes, so update now.

As of Wednesday 21 October 2026, 15:30 BST, PHP has released fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says both vulnerabilities can allow unauthenticated remote code execution, and that updating is the only complete fix. We have not verified exploitation in the wild in the sources we reviewed. That is not evidence that systems are safe.

PHP has released security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both are scored CVSS v4.0 9.2. PHP says they can allow unauthenticated remote code execution, which means an attacker could run their own code on a server running PHP without logging in. PHP also lists memory disclosure as a confirmed impact.

PHP’s advisory says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

What PHP has confirmed

PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026. Each fixes both vulnerabilities..

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), “RCE via OOM corruption”. Out-of-memory handling can interrupt PHP while internal request data is only partly set up. Request clean-up can then treat that invalid data as valid.
    .
    .
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), “RCE via stale global state”. Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker can use that stale state before PHP resets it. Session upload progress is one confirmed path. On PHP 8.5, the fatal-error backtrace is another.
    .
    .
  • PHP says the confirmed impact is unauthenticated remote code execution with the privileges of the web worker account. For CVE-2026-109619 it also lists memory disclosure.
    .
    .
  • PHP validated remote code execution over HTTP against mod_php with default PHP input and memory limits (CVE-2026-109618). For CVE-2026-109619 it validated remote code execution against mod_php, and a session-handling path against FPM.
    .
    .
  • PHP says FPM is susceptible by source analysis for CVE-2026-109618, but no complete FPM exploit has been demonstrated for it. It says FrankenPHP is likely susceptible, and that LiteSpeed (LSAPI) application-specific exploits are likely but unvalidated.

PHP says there is no complete mitigation. Updating is the only safe choice.

Details of the vulnerabilities reportedly leaked online on 20 October, before PHP’s coordinated disclosure.

Confirmed research

Wiz Research, which reports finding the flaws, has published its own findings. Wiz reports demonstrating unauthenticated code execution against container images that were latest at the time of testing. It also reports a separate demonstration of reading sensitive data from PHP process memory, including passwords, tokens and API keys, without first achieving code execution.

These are examples of the underlying PHP issues. They are not separate vulnerabilities in WordPress, Drupal or Joomla, and they are not evidence of attacks against customers. Wiz says exploitation does not depend on flaws in application code, and that these platforms were chosen as representative targets.

What is not yet known

  • Exploitation in the wild. We have not verified it in the sources we reviewed, as of 15:30 BST. Third-party write-ups and purported proof-of-concept code are public. The absence of confirmed reports is not evidence that systems are safe.
  • How exploitable each version and configuration is. PHP says exposure to CVE-2026-109619 depends on configuration and on the internal state involved, and that attack complexity is high. Wiz notes that PHP version, configuration and application behaviour can change whether an exploit works. Do not assume every version and setup is equally exploitable, and do not assume yours is safe.
    .
  • Other variants. PHP says its complete patch resets wider request state, and that no generic configuration covers every path.

Branch support status

PHP’s lifecycle page lists these dates as of 21 October 2026.

Branch Support status Security support until Fixed in
8.5 Active support until 31 Dec 2027 31 Dec 2029 8.5.12
8.4 Active support until 31 Dec 2026 31 Dec 2028 8.4.27
8.3 Security fixes only (active support ended 31 Dec 2025) 31 Dec 2027 8.3.36
8.2 Security fixes only (active support ended 31 Dec 2024) 31 Dec 2026 8.2.35
8.1, 8.0, 7.x, 5.x End of life, no upstream security updates Ended No upstream update

 

PHP’s advisories list affected versions only for the four supported branches: everything below 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Wiz reports that affected releases date back to PHP 5.4. That is Wiz’s finding, not a PHP statement. It does not mean every version and configuration is equally exploitable.

PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and long-term support vendors provide backported fixes. PHP also published minimal source backports for PHP 7.4, 8.0 and 8.1 for people who build from source or have no access to a long-term support vendor. Contact your vendor, or move to a supported version.

PHP 8.6.0 RC3 (8 October 2026) is a release candidate. PHP says not to use release candidates in production.

Exploitation status

PHP’s advisories describe validated remote code execution against mod_php for both vulnerabilities, and against FPM through a session-handling path for CVE-2026-109619. Wiz reports unauthenticated code execution against WordPress, Drupal and Joomla deployments. Third-party write-ups and purported proof-of-concept code are also public.

As of 15:30 BST on 21 October 2026, we have not verified exploitation in the wild in the sources reviewed. That is not evidence that systems are safe. No indicators of compromise specific to these vulnerabilities have been confirmed.

Our initial testing of pre-release third-party code did not reproduce a crash or remote code execution. Those results concern that material, not the vulnerabilities PHP and its reporting researchers have now validated.

The reported use-after-free memory corruption can crash PHP processes and disrupt a service, even if a malicious payload is removed from a test. We do not have a validated, non-disruptive proof of concept for assessment. Don’t run exploit code against production.

PHP says the producing and consuming requests for CVE-2026-109619 must reach the same worker. It says multiple workers and recycling reduce the success rate per request but do not remove the condition.

Potential impact

If an attacker exploits either vulnerability on a server you run, PHP says they can run arbitrary code with the web worker’s privileges, without logging in.

If a flaw is exploitable in your deployment, an attacker could:

    • run arbitrary code on the server
    • reach application data and secrets
    • change site content
    • plant malicious server-side files
    • disrupt services. The reported flaw type, use-after-free memory corruption, could also crash PHP processes. Even a trimmed-down test could do this, so don’t run leaked exploit code against production.

Data exposure without code execution. PHP’s advisory for CVE-2026-109619 lists memory disclosure as a confirmed impact. Wiz reports recovering passwords, tokens and API keys from PHP process memory without first achieving code execution. That memory can include data from other requests handled by the same worker, and data belonging to the server itself.

This means data exposure needs investigating even where you find no web shell and no malicious file. If an unpatched, internet-facing PHP server could have been reached, treat secrets it handled as potentially exposed. Consider rotating credentials, tokens and API keys that the PHP process held or could read. We have no confirmed reports of this happening to a CovertSwarm client or to anyone else.

The extent to which they can proceed depends on the permissions of the PHP process and on what it has access to, for example databases, cloud credentials, and internal services. It’s not advisable to assume that root or administrator access is available.

PHP is embedded widely: in content management systems such as WordPress, Drupal, Joomla and Magento, in shared hosting, in control panels such as cPanel and Plesk, and in vendor software and appliances that bundle php.exe or php-cgi.exe. Your exposure may sit in software you didn’t install as PHP.

Recommended actions

  1. Update PHP to a fixed version. Use 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Put internet-facing systems first, then systems that handle sensitive data. Include container images, bundled runtimes and extra instances.
  2. Inventory PHP. Cover web servers, containers, managed hosting, control panels and third-party software. Record internet exposure, owner, support status and the runtime that serves web requests, not just the command-line install.
  3. .Handle end-of-life PHP. PHP 8.1 and older get no upstream update. Ask your vendor whether it has a backported fix, or move to a supported branch. PHP’s source backports for 7.4, 8.0 and 8.1 are for people who build from source or have no vendor support.
  4. Confirm third-party fixes. For distribution packages, managed hosting and software that bundles PHP, ask the provider to confirm the fix is available and deployed. PHP says Linux distributions and long-term support vendors received the patches in advance, so check your vendor for updated packages.PHP also says the volunteer-maintained rpms.remirepo.net repository will not have updates today. A backported fix can keep an older upstream version string, so check the package revision and the vendor advisory, not just the PHP version number. Package repositories and provider rollouts may lag the upstream release. Refreshing package indexes alone (for example, apt update) does not install or verify the fix. A provider’s promise of automatic patching is not confirmation that your systems are patched.
  5. If you cannot update yet, reduce exposure. PHP says these measures reduce exposure to specific attack paths but do not make an installation safe. Assess the effect on your service first, and restart every PHP worker after configuration changes.CVE-2026-109618. Set memory_limit=-1, in a way applications cannot override (for example php_admin_value in the FPM pool or Apache configuration), and check that no pool, directory or application setting restores a finite limit. Set a low post_max_size(PHP suggests 8M if you don’t need uploads, 32M if you do) and keep upload_max_filesize below it. Enforce limits for decoded request size, input fields, multipart parts, headers and nesting depth at the web server or proxy, including for requests without a usable Content-Length. A container or cgroup memory limit can act as an availability boundary, ideally one that kills only the affected worker. Don’t use RLIMIT_AS or RLIMIT_DATA: PHP says they can cause the vulnerable allocation failure.

    CVE-2026-109619. Set session.upload_progress.enabled=0 in php.ini, an FPM pool or server configuration that applies before request parsing, not through ini_set() or .user.ini. PHP says this blocks the confirmed session paths but not other variants. On PHP 8.5, set fatal_error_backtraces=0, which blocks the confirmed fatal-backtrace path only. Remove invalid or deprecated per-request settings that emit diagnostics before initialisation, because hiding diagnostics with error_reporting, display_errors or @ does not help. Fix attacker-reachable fatal errors and execution timeouts.

  6. Don’t rely on a WAF or generic hardening. PHP says no generic configuration mitigation covers every path, and that updating is the only reliable fix. Keep a WAF and hardening as defence in depth, not as a replacement for the update. A provider’s report of WAF coverage is not confirmation that your deployment is protected.
  7. Investigate, don’t just patch. These issues run below the application layer, so application logs may hold little context. Look for the following and correlate them:
    • unusual multipart request traffic
    • memory-limit errors, especially after multipart requests
    • repeated HTTP 500 responses
    • abnormal or unexpectedly large PHPSESSID response cookies
    • unexplained PHP worker restarts
    • unexpected child processes from PHP workers (php-fpm, php-cgi, httpd, apache2) launching shells, interpreters or download tools
    • unexpected executables in web directories, unusual outbound connections and unauthorized scheduled tasks.These are investigation leads, not proof of exploitation. Their absence does not establish that a system is safe. They are not confirmed detection signatures for these vulnerabilities. PHP also suggests auditing Apache, PHP-FPM, reverse proxy and service logs for repeated warnings or deprecations before scripts run, fatal, parse and uncaught errors, and “Maximum execution time exceeded”. PHP says a clean log is not proof of safety.
  8. Verify after patching. Confirm the updated runtime is active everywhere. If you suspect compromise, preserve evidence, isolate the system, and investigate the credentials it could reach. Patching doesn’t remove persistence or reverse credential theft.

Last updated: Wednesday 21 October 2026, 15:30 BST. We will update this post if PHP or other sources publish further confirmed information.

Sources