Security Alert: Critical PHP Vulnerabilities Put Most of the Web at Risk

Every few years, a vulnerability surfaces in software so deeply embedded in the internet that nearly every organization is affected at once. Heartbleed was one. Log4Shell was another. This time, it’s PHP2Shell.

The PHP project has released emergency patches for two critical vulnerabilities that let an attacker run code on a web server and take control of it without logging in. CVE-2026-109618 and CVE-2026-109619 both carry a CVSS score of 9.2.

Attackers can also use the vulnerabilities to read passwords, API keys, and other secrets straight from server memory. The flaws sit in PHP itself, not in any single application, so every website and web application built on PHP is potentially exposed.

Coalition urges every organization running PHP to patch immediately. Our threat intelligence team began observing exploit-related activities more than five hours before PHP released its fix, and activity has grown since. We expect these vulnerabilities to be exploited at scale. 

Coalition sent an initial Zero-Day Alert to some policyholders running known vulnerable versions of PHP on October 20, prior to the public disclosure of the vulnerabilities. Our team will continue outreach efforts as the broader exposure of the vulnerabilities develops, and we will update this blog on an ongoing basis as new information becomes available.

What we know

PHP powers roughly 7 in 10 websites whose server-side language is known and also runs many of the admin tools businesses use to manage firewalls, databases, phone systems and backups.

PHP published its advisory on October 21, a day earlier than planned after details leaked online, urging all PHP users to update immediately.

• CVE-2026-109618 is a remote code execution (RCE) vulnerability caused by how PHP handles running out of memory.

• CVE-2026-109619 is an RCE caused by leftover data from one web request being reused by the next.

Wiz Research, which found the flaws in collaboration with Calif and OpenAI, also showed that attackers can read sensitive data from server memory without taking over the server. That data can include passwords, authentication tokens, API keys, and certificates. The affected code dates back to PHP 5.4, released in 2012, so effectively every version in use today is vulnerable.

PHP says all installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It considers the risk highest for Apache with mod_php, where it has demonstrated a working exploit.

Neither CVE was on CISA's Known Exploited Vulnerabilities (KEV) list at the time of writing.

What Coalition honeypots are seeing

Coalition runs a global network of honeypots, decoy systems that record what attackers send across the internet. Between October 20 and October 21, our threat intelligence team tracked requests matching the patterns used to exploit the PHP2Shell vulnerabilities.

• Attackers moved before the patch: The first exploit-related requests reached our sensors at 08:00 UTC on October 21, more than five hours before PHP released its fix. Some referenced "p2shell," the name used by exploit tools now circulating online.

• Reconnaissance spiked just before the release: Between 12:00 and 13:00 UTC, requests for phpinfo pages jumped to 3,839, compared with about 100 in a typical hour. These pages (when exposed to the public internet) reveal a server's exact PHP version and configuration, which attackers use to pick targets.

• Activity jumped after the advisory: In the three hours after PHP's release, we logged 133 requests abusing the upload-progress feature these attacks rely on, compared with 28 in the hours before release.

• Attackers are moving from probing to exploitation: About 2.5 hours after the release, we saw the first requests built to trigger the out-of-memory flaw behind CVE-2026-109618.

These numbers are still small, which is typical in the first hours after disclosure. Attackers were preparing before a patch existed and began attempting exploitation within hours of initial disclosure. (We will update this section as more data becomes available.)

How widespread is the exposure?

PHP is reportedly used by 69.3% of websites whose server-side language is known. For context, WordPress, which runs on PHP, accounts for 39.6% of all websites on its own.

Most WordPress sites sit with hosting providers that will, at some point, roll out patched PHP builds. However, speed is of the essence. Those sites still need updating, but they rarely hold critical data and can usually be restored quickly. The bigger concern is everything else that runs on PHP.

Coalition data reveals exposure is spread across every PHP branch, not concentrated on the newest releases. A meaningful share of vulnerable assets run end-of-life versions (8.1 and older) that will not receive an official fix. These systems are often the hardest to patch and the easiest to forget.

Why the real risk goes beyond websites

Many of the tools businesses use to run their IT are built on PHP. These admin interfaces hold credentials, configuration, and control over critical systems. If one is exposed to the internet, a single request could give an attacker a foothold that leads to a much larger incident. Examples include:

• Database administration tools, such as phpMyAdmin and Adminer, which give direct access to business data.

• Firewalls and network appliances, such as pfSense and OPNsense, which hold VPN credentials and control network access.

• Backup administration consoles, such as Bacula-Web and Bareos WebUI. Attackers who reach backups can destroy or encrypt them, which makes ransomware far more damaging.

• IT monitoring and asset management tools, such as Zabbix, Nagios XI and GLPI, which store credentials for many other systems.

• Phone system admin panels, such as FreePBX, a common target for toll fraud and call interception.

These are the systems to find and patch first.

Recommended action

1. Find every PHP system

Inventory your websites, internal tools, and vendor appliances that run PHP, including copies bundled with control panels, such as cPanel and Plesk. Start with the admin tools listed above. Coalition Control policyholders can go to Assets → Technologies and search for PHP.

2. Update PHP now

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, then restart PHP-FPM or your web server so the new version loads. If you install PHP through a Linux distribution or hosting provider, apply their updated packages. Their version numbers may not match PHP's, so confirm with your vendor that the fix is included.

3. Deal with end-of-life versions

PHP 8.1 and older will not get an official patch. Upgrade to a supported version, or ask your vendor for a backported fix. Until then, take these systems off the internet.

4. Reduce exposure if you can't patch right away

Take PHP applications off the internet or put them behind a web application firewall (WAF). Cloudflare, Akamai, AWS, Fastly, Google Cloud, and other providers have prepared WAF protections for these vulnerabilities.

Then apply these temporary settings:

• Set session.upload_progress.enabled=0 in php.ini or your server configuration, then restart all PHP workers.

• Set memory_limit=-1 in a way applications can't override, and keep post_max_size low (8M, or 32M if your application needs uploads).

• On PHP 8.5, also set fatal_error_backtraces=0.

• If your application doesn't accept file uploads, block multipart/form-data requests at your web server or WAF.

These settings reduce risk but do not fix the vulnerabilities. Only updating does.

5. Check for compromise

Look for PHP processes starting shells or tools like curl or wget, new or changed files in your web root, and new cron jobs or user accounts. Because the attack happens below the application, app logs may show little. Wiz recommends also watching for:

• Web requests carrying file uploads followed by out-of-memory errors or a run of HTTP 500 errors

• Oversized or garbled session cookies (PHPSESSID) in server response

• PHP workers that crash or restart repeatedly without explanation

6. Report suspicious activity

Coalition policyholders who find signs of compromise should contact the Coalition claims team immediately.

Next steps

Coalition will continue proactive outreach to policyholders using PHP, monitor for exploitation, and update this guidance as new information emerges. 

EASILY SPOT & STOP CYBER THREATS IN ONE PLACE

Coalition Control

Take control of your cyber risk >

This blog post is designed to provide general information on the topic presented and is not intended to construe or render legal or other professional services of any kind. If legal or other professional services are required, the services of a professional should be sought. Descriptions of coverage are for general informational purposes only and are subject to the terms and conditions, including the limitations and exclusions, of the applicable policy. The reader is cautioned to consult independent professional advisors and formulate independent conclusions and opinions regarding the subject matter discussed herein. Coalition makes no representations as to the accuracy or completeness of this content. Any action taken based on this information is at the sole discretion and risk of the reader. Coalition and its affiliates expressly disclaim any liability for losses or damages resulting from the use of or reliance on this information, which is used strictly at the reader’s own risk. The blog post may include links to other third-party websites. These links are provided as a convenience only. Coalition does not endorse, have control over nor assume responsibility or liability for the content, privacy policy or practices of any such third-party websites.

Copyright © 2026. All rights reserved. Coalition and the Coalition logo are trademarks of Coalition, Inc.