Critical PHP Vulnerabilities: What Your Business Needs to Do Now

If your business runs a website, a client portal, or a line-of-business app, there's a good chance PHP is running somewhere underneath it. On October 21, 2026, the PHP project released emergency security updates for two critical vulnerabilities that let an attacker take control of an affected server without logging in.

Attackers aren't waiting. Exploitation attempts have already been reported, so this one belongs at the top of your IT team's list today. 

Publish and Update History

Published at 8:00 AM CT on October 23, 2026.

What happened with PHP

PHP is the server-side programming language behind countless websites and web applications, including popular platforms like WordPress, Drupal, Joomla, and Magento. On October 21, the PHP security team released fixes for two flaws, both rated Critical: 9.2 out of 10 by PHP and 9.8 by NIST's National Vulnerability Database. 

• CVE-2026-109618: A problem in how PHP handles running out of memory. An attacker can trigger it mid-request and corrupt memory in a way that leads to remote code execution.
• CVE-2026-109619: Leftover data from one web request can be reused by the next one after its memory has been freed. That can expose data or let an attacker run their own code. 

Researchers have nicknamed the pair "php2shell." The release was moved up a day after the vulnerability IDs leaked publicly ahead of schedule. 

Why these PHP vulnerabilities are serious 

Several details make this more urgent than a routine patch cycle. 

No login required. An attacker doesn't need a username or password. In some configurations, a single crafted web request can trigger the attack before your application code even runs.

The affected code goes back years. Researchers traced the vulnerable code path to PHP 5.4, released in 2012. Older servers that haven't been touched in a while are among the most exposed.

Attackers are already probing. Arctic Wolf Labs observed widespread scanning and active exploitation attempts shortly after disclosure, including attempts to deliver malware. CISA hadn't confirmed exploitation when it issued its alert, but urged organizations to patch immediately.

Federal agencies are sounding the alarm. CISA urged organizations to patch immediately and said any system that can't be updated, or that's running PHP 8.1 or older, should be taken offline until it is. The NSA warned that attackers are likely to weaponize these flaws. 

Is your business affected?

Any server running PHP to serve web requests is potentially at risk. That includes common setups like Apache with mod_php (the highest-risk configuration, according to PHP), PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed.

PHP versions that need updating

The PHP project has released patched versions for every supported branch. Here's where each one stands: 

Software you didn't build yourself

Don't stop at the servers your team manages directly. As CISA puts it, PHP is often a component of other software, so you may not see it directly. Content management systems, hosted portals, and network or security appliances can all run PHP behind the scenes. Check with each of your software partners to confirm whether their products are affected and when patches will be available.

What to do right now

Updating PHP is the only complete fix. Here's how we recommend working through it:

1. Build your inventory. Identify every server, container, and hosted service running PHP.
2. Patch internet-facing systems first. Public websites and portals carry the most risk. Update them, restart all PHP workers, and rebuild any container images.
3. Upgrade end-of-life versions. PHP 8.1 and older won't get an official fix. CISA recommends taking these systems offline until they're upgraded to a supported version.
4. Add a web application firewall rule as a stopgap. Several cloud and WAF providers have released rules that block known attack patterns. These buy you time. They aren't a replacement for patching.
5. Turn up logging and review recent activity. Review logs from the days before and since disclosure. Watch especially for PHP processes launching command shells or downloading tools, and keep enhanced logging on while you patch. 

If you can't patch right away, PHP has published temporary configuration changes that reduce exposure to specific attack paths, and restricting file upload forms that aren't needed for daily business helps too. Neither makes a server safe. If an internet-facing system can't be updated, CISA's guidance is to take it offline until it's fixed. 

Signs a server may already be compromised

Details of these flaws leaked a day before the patches were released, and attackers moved quickly, so updating PHP doesn't tell you whether a system was already hit. Watch for these warning signs on any server that was running a vulnerable version:

• Website files that were created or changed without explanation
• Unexpected administrator accounts, scheduled tasks, or login activity
• Web server processes running unfamiliar commands or programs
• Unexplained outbound network connections from a web server
• Unexpected website changes, redirects, or error messages
• More frequent server crashes, memory errors, or web service restarts
• Security alerts involving web shells (hidden tools attackers use to control a server), remote access, or suspicious commands 

If you spot any of these, isolate the affected server where you can and bring in your security or hosting team. Preserve your web, firewall, and system logs before making major changes. That evidence shows how far an attacker got and what needs to be cleaned up. 

Frequently asked questions about the PHP vulnerabilities

Here are answers to the questions we're hearing most from business leaders this week.

Is my WordPress site affected?

WordPress itself isn't the problem. The PHP version running underneath it is. Researchers have demonstrated attacks against specific versions of WordPress, Drupal, Joomla, and Magento. If your site is hosted, ask your hosting provider which PHP version you're on and when it will be patched. 

What else uses PHP besides websites?

More than most people expect. PHP often runs inside other software, where the people using it never see it. Common places include:

• Content management and ecommerce platforms, such as WordPress, Drupal, Joomla, and Magento
• Client portals, intranets, and custom web applications
• Web-based management consoles on network, security, and communication systems
• Prebuilt cloud applications and hosted services
• Hosting control panels, such as cPanel and Plesk 

Vendor software often includes PHP without saying so, and standalone PHP files on Windows servers are often overlooked. If you're not sure whether a product uses PHP, ask its provider directly whether it's affected and when a fix will be available.

Is updating my application enough?

No. These flaws are in PHP itself, so updating a plugin or theme won't fix them. The PHP runtime has to be updated, and its workers restarted.

We use a managed hosting provider. Do we need to do anything?

Confirm it. Some platforms patch automatically. Others only patch supported versions or require you to redeploy. Get a clear yes from your provider, in writing if possible.

How the attack works: technical details for IT teams

For IT and security teams, here's a closer look at both flaws and what attackers do after exploiting them.

• CVE-2026-109618 (out-of-memory corruption): PHP enforces its memory limit by abruptly stopping a request that exceeds it. If that happens while PHP is still setting up request data, such as parsing a file upload, the cleanup that follows can treat partially set-up memory as valid. That memory may still hold data the attacker controls.
• CVE-2026-109619 (stale global state): Internal state from one request can survive after its memory is freed, for example after a fatal error. The next request handled by the same worker can use that stale state before it's reset. PHP's session upload progress feature, which is on by default, is one confirmed path to this flaw.
• Highest-risk setup: PHP rates Apache with mod_php as the highest risk. In PHP's demonstrated exploit, a single unauthenticated request triggers the attack before any application code runs.
• Data exposure: Beyond code execution, researchers demonstrated that an attacker can pull secrets out of server memory, such as database passwords and API keys.
• After exploitation: A successful attack gives the attacker command execution as the web server user. Security researchers describe this as a foothold for planting web shells, harvesting credentials from configuration files, and moving deeper into the network. 

For full technical analysis, including attack diagrams, see research from these security teams:

• Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities
• Datadog Security Labs: PHP2Shell detection, analysis, and remediation
• CrowdStrike: CrowdStrike Protects Customers from Threats Delivered via PHP2Shell
• Arctic Wolf Labs: Finding, Prioritizing, and Patching PHP2Shell Exposure
• Arctic Wolf Labs: PHP2Shell: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution

For Marco's Managed IT clients

As shared in our recent client notice, please contact our Support Desk if you have questions about these PHP vulnerabilities or would like help determining which of your devices are affected:

• Submit a ticket via the portal: portal.marconet.com
• Chat: Start a ticket in mChat
• Phone: 800-847-3097

Additional resources

For full technical details and the latest official guidance, see these sources:

• PHP: Security advisory and fixed versions
• PHP: Supported versions and end-of-life dates
• NIST National Vulnerability Database: CVE-2026-109618
• NIST National Vulnerability Database: CVE-2026-109619
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• NSA: Critical Patches Recommended for PHP Vulnerabilities