October 2026 PHP Vulnerability Analysis

Overview

On October 21, 2026, the PHP project disclosed two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619. The PHP project rates both at 9.2 (Critical) on CVSS v4.0. Under certain configurations, an unauthenticated attacker can use crafted HTTP requests to run code on a vulnerable PHP server. The PHP project also confirms that it can disclose process memory. This article shows you how to find affected internal assets and third parties in SAFE, and how to respond.

Which PHP versions are affected

Research cited in the SAFE blog traces the affected code back to PHP 5.4. That is a code-history finding, not a test of every release.

Why this matters now

• CloudFlare reported attack traffic against internet-facing hosts on the day of release, and Unit 42 reported proof-of-concept activity. Neither confirms a successful compromise.
• SAFE reproduced the full code-execution chain against a PHP 8.4.26 Apache (mod_php) lab setup. The same exploit stopped at the memory-leak stage against PHP 8.4.27.
• Servers running mod_php are the clearest exposure. Servers running PHP-FPM have conditional exposure through CVE-2026-109619 and should be treated as vulnerable until patched.
• Because the vulnerable state is shared across requests handled by the same worker, other applications on the same server can share the exposure.

Check your exposure in SAFE

1- Use the in-app advisory

Log in to SAFE. The Critical Safe Security Advisory: Assess Impact of PHP Vulnerabilities pop-up opens.

Select View Impacted Internal Asset to see your internal assets that are exposed. Select View Impacted Third-parties to see your third parties that are exposed.

2- Filter findings by CVE

You can also navigate to Findings, and filter by CVE ID and enter CVE-2026-109618 and CVE-2026-109619. Review the affected assets and the number of impacted systems.

3- Ask Safe-X

1. Open Safe-X.
2. Turn on Deep Search.
3. Ask which assets are affected by CVE-2026-109618 and CVE-2026-109619.

4- Find third parties that use PHP

1. Go to Third Parties and open Fourth Parties.
2. Search for PHP.

This list shows which third parties use PHP. However, keep in mind, it does not check whether they run a vulnerable version.

Respond to what you find

1. Patch or upgrade. Move to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12. This is the only complete fix. For end-of-life branches, use a vendor-supported backport, the official source backport, or migrate to a supported branch. Prioritize internet-facing and business-critical systems first.
2. Restart every PHP worker after patching. Restart Apache fully for mod_php, or restart the pool for PHP-FPM. The vulnerable state lives in running workers, so a patched binary alone does not remove it.
3. If you cannot patch yet, apply stopgaps. None of these is a complete fix.
   • Set session.upload_progress.enabled=Off to block the confirmed early upload-progress path.
   • On PHP-FPM, lower pm.max_requests to recycle workers more often. The PHP project suggests 1 if performance allows.
   • Do not cap PHP with RLIMIT_AS or RLIMIT_DATA, because these limits can trigger the vulnerable allocation failure.
   • Turning display_errors off does not protect against CVE-2026-109619, according to the PHP project.
4. Add edge controls. At your front end, limit decoded request size and bound multipart part count, headers per part, empty file controls, input variable count and nesting depth. Make sure the limits also cover requests without a usable Content-Length.
5. Hunt for exploitation. Look for these indicators.
   • PHP fatal errors reading "Allowed memory size exhausted" with "Unknown on line 0", especially with no matching application log line.
   • Multipart POST requests with thousands of parts, empty filename controls with deeply nested field names, or no usable Content-Length.
   • Apache worker crashes (SIGABRT, SIGSEGV, "zend_mm_heap corrupted") followed by requests from the same client.
   • Pairs of requests from one source using PHP_SESSION_UPLOAD_PROGRESS with PHPSESSID values of unexpected length or content.

An unusual cookie alone is a lead, not proof of exploitation.

1. Contact affected third parties. Ask whether they run a vulnerable version and what they are doing about it.
2. Re-check in SAFE after remediation to confirm the findings clear.

Get help

SAFE Threat Intelligence can walk you through the vulnerabilities or how SAFE responded. Contact your Customer Success Manager or SAFE Support.

• SAFE Threat Research: PHP2Shell

Did this article help?

Let us know by leaving a star rating at the top of this article.