PHP CVE-2026-109619: Exploited RCE Flaw and How to Patch

PHP has a critical flaw, tracked as CVE-2026-109619, that can allow unauthenticated remote code execution. CISA added it to its Known Exploited Vulnerabilities catalog on 2026-10-26, which means exploitation in the wild is recorded. The PHP project has released fixed versions.

If you run PHP on your own servers, VPS or managed hosting, this affects you. Site owners on shared hosting should ask their provider which PHP build they run and when it was updated.

What happened

The PHP maintainers published a security advisory on October 21, 2026, rating the issue critical. The CVE record gives it a CVSS score of 9.2 and lists CWE-416 (use after free), CWE-755, CWE-824 and CWE-1325. CISA's catalog entry, which also lists CWE-1419, describes it as a stale internal request-state vulnerability that allows unauthenticated remote code execution. The NVD entry uses the same description.

CISA added the CVE to the catalog on 2026-10-26 with a due date of 2026-10-29 for federal agencies, and marks forensic triage as required under its BOD 26-04 directive. Whether it has been used in ransomware campaigns is listed as unknown. The research does not say who is exploiting it, how many sites are affected or what the attacks look like, so we do not speculate on that.

Technical details in plain terms

PHP keeps some global state, such as error, session, object and extension state, that points into memory owned by a single request. That state is supposed to be cleared before the request memory is released. According to the advisory, some operations run before the next request is fully initialized and can read state that was never reset. The result is a use-after-free, and the advisory says a carefully crafted heap layout can turn it into full remote code execution.

Exploitation needs two parts: a producer and a consumer. The producer leaves request-owned state behind, for example because a fatal error (including a memory exhaustion error or a maximum execution time error) interrupted an operation before it cleaned up. The consumer is a later operation in the same worker that acts on that stale state. The advisory says the demonstrated producing and consuming steps happen in different HTTP requests handled by the same worker.

The confirmed consumer: early INI diagnostics

The advisory names two confirmed consumers before normal initialization. One is a warning, notice or deprecation raised while applying invalid or deprecated INI settings at the start of a request. It does not need to be displayed or logged. The advisory states that changing error_reporting, using the @ operator, or disabling display_errors or log_errors does not protect against the issue.

Who is exposed

Exposure depends on how PHP is run, because the vulnerable step relies on configuration being applied at the start of each request. The advisory describes these cases:

• Apache with mod_php: .htaccess and Apache php_value, php_flag and php_admin_* directory settings are applied before request startup, so they are a reachable path.
• PHP-FPM: conditionally exposed when nginx, Apache mod_proxy_fcgi or another frontend sends PHP_VALUE or PHP_ADMIN_VALUE parameters that produce a diagnostic before request initialization.
• Not the same early path: normal php.ini is startup configuration and is not reapplied across requests. The advisory also says FPM pool values are applied when a worker starts and .user.ini is applied after normal initialization, so they do not provide the same early access (the source text is truncated at this point, so confirm details in the full advisory).

The advisory also says the exact affected configurations and mitigations depend on the internal state involved. Do not assume you are safe because your setup looks unusual; patching is the reliable answer.

Affected and fixed versions

The advisory lists no other branches. If you run a PHP version outside these four branches, check the vendor advisory and your distribution's notes rather than assuming it is unaffected.

How to check your exposure

1. List every place PHP runs: web servers, containers, staging and CI images, and any hosting accounts you manage.
2. Run php -v (and check the PHP-FPM or Apache module version, which can differ from the command-line binary) and compare against the table above.
3. Linux distributions often backport fixes without changing the upstream version number. Check your distribution's security tracker or package changelog for CVE-2026-109619 instead of relying on the version string alone.
4. Find out how PHP is invoked: look for php_value, php_flag or php_admin_* lines in Apache config and .htaccess files, and for PHP_VALUE or PHP_ADMIN_VALUE fastcgi_param lines in nginx or proxy_fcgi setups.
5. On shared or managed hosting, ask the provider to confirm the patched version in writing.

What to do now

1. Upgrade to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or the newer release in your branch), or install your distribution's patched package.
2. Restart PHP-FPM, Apache or whatever hosts your PHP workers after updating, since the flaw involves long-lived workers.
3. Where you cannot patch immediately, follow the mitigations in the vendor advisory and review configuration that sets PHP values per directory or per request. Remember that hiding errors does not mitigate this.
4. Treat internet-facing servers as the priority. CISA's guidance tells stakeholders to assess each asset's internet exposure.
5. Because exploitation is recorded, check patched servers for signs of earlier compromise, as described below.

Detection and monitoring

The research gives no indicators of compromise, so we cannot list specific log signatures. CISA marks forensic triage as required, which is a good reason to look back rather than only patch forward. Sensible checks include:

• Unexpected PHP files, modified files or new files in web roots and upload directories.
• New or changed admin users, cron jobs, scheduled tasks and SSH keys.
• Bursts of PHP fatal errors, memory exhaustion or timeout messages in logs shortly before unusual activity, since the advisory lists these as ways stale state can be produced.
• Unexpected outbound connections from web servers.

If you find signs of compromise, follow our guide on what to do when a website is hacked. An outside-in scan cannot see inside your server, so read about what outside-in malware detection can and cannot see. For ongoing visibility into changes on your public site, monitoring can alert you to certificate, DNS and header changes, though it does not patch or detect this specific flaw.

Timeline

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

• RCE via stale global state (github.com)
• Known Exploited Vulnerabilities Catalog | CISA (cisa.gov)
• PHP Stale Internal Request-State Vulnerability (CVE-2026-109619) is being actively exploited (nvd.nist.gov, 26 October 2026)

Tags: PHP, CVE-2026-109619, RCE, CISA KEV, patching