PHP2Shell Patch Guide: Fix CVE-2026-109618 & 109619 Fast

PHP2Shell: Critical PHP Flaws (CVE-2026-109618 & CVE-2026-109619) Need Patching Now

Quick Answer
PHP2Shell is a pair of critical PHP flaws (CVE-2026-109618, CVE-2026-109619) that can allow unauthenticated code execution. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart workers, and verify every web-facing pool.

Last verified: October 22, 2026. This is a fast-moving story, so details may change as vendors and researchers publish more.

Picture a SOC lead opening the queue on Wednesday morning. Overnight, a forum post claimed two PHP remote code execution vulnerabilities had leaked. By lunchtime, the PHP project had shipped an emergency PHP security update, and the one question on every bridge call was the same: "Where do we run PHP, and who owns it?"

That scenario is hypothetical, but the timeline is not. Per the PHP security team's advisories, patches for the flaws now called PHP2Shell were released on October 21, 2026. If your organization runs WordPress, Drupal, Laravel, legacy intranet apps, or anything else on PHP, this one is yours to triage.

Table of Contents

• What Happened: The PHP2Shell Timeline
• The Two Flaws in Plain Language
• Affected and Fixed Versions
• Is It Being Exploited?
• How to Verify Your PHP Version (Correctly)
• Emergency Patch Management: A Practical Order of Operations
• Temporary Mitigations (and Their Limits)
• WAF Protection as a Stopgap
• Detection: What a SOC Should Hunt For
• Expert Tips
• FAQ
• Conclusion

What Happened: The PHP2Shell Timeline

According to reporting by BleepingComputer, the PHP security team warned administrators on October 20 to prepare for emergency updates the next day. Details were reported to have leaked ahead of the scheduled disclosure, and PHP said it reserved the right to release early if details became public or exploitation appeared in the wild.

The patches landed on October 21, 2026, at the announced 14:00 UTC release window. BleepingComputer reports the flaws were discovered by researchers at Calif, OpenAI, and Wiz.

One detail worth correcting in your own write-ups: The Hacker News noted that a leaked claim of a CVSS 10.0 score was not PHP's number. The PHP project rates both flaws 9.2 under CVSS 4.0.

The Two Flaws in Plain Language

Both issues sit in the PHP runtime itself, not in a plugin or framework. That means a site can have perfectly clean application code and still be exposed. Here is what the PHP advisories describe, simplified.

CVE-2026-109618: Out-of-memory handling

Historically, when PHP ran out of memory during a request, it used a mechanism called longjmp() to abandon the current operation. In some situations that abrupt exit left request data partly initialized. PHP's later shutdown process could then act on that invalid data, which opens a path to code execution.

Per the advisory, multipart form data can help drive the memory pressure, for example through many headers in a single part or many empty file fields that still create metadata. The advisory also describes a case where a multipart request without a usable content length can slip past an early size check.

CVE-2026-109619: Stale global state

This one involves long-running workers. A worker can keep a reference to memory from a request after PHP has already freed it. If cleanup is interrupted and a later request touches that leftover state, the worker may use invalid memory. BleepingComputer's summary says this can lead to use-after-free, memory disclosure, and code execution with the web worker's privileges.

Analysis: The common thread is that failure paths, not normal request handling, are where these bugs live. That is why default limits and "my app validates input" do not give you comfort here. The advisory says the vulnerable state can be reached before application code even starts.

Affected and Fixed Versions

PHP branch	Vulnerable	Fixed in
8.5	Earlier than 8.5.12	8.5.12
8.4	Earlier than 8.4.27	8.4.27
8.3	Earlier than 8.3.36	8.3.36
8.2	Earlier than 8.2.35	8.2.35

Older branches are murkier. Reports differ on how far back the problem goes, with Wiz and SecurityWeek saying nearly all releases back to PHP 5.4 are affected. SecurityWeek also reported that minimal source backports were released for PHP 7.4, 8.0, and 8.1. If you run an end-of-life branch, check with your Linux distribution or long-term support vendor, because they may ship a fix under an unchanged version number.

Which server setups are exposed? The PHP advisory lists any installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The project considers the risk highest for mod_php, where a demonstrated attack triggers before any application code runs.

Is It Being Exploited?

Reports vary slightly, so treat this section carefully.

• Confirmed by multiple outlets: Cloudflare's CTO said the company was seeing early attacks emerging and updating its mitigations as new vectors appeared.
• Reported by SecurityWeek: a security firm said it was seeing exploitation in the wild at scale after the patches shipped.
• Reported by Paubox: as of the afternoon of October 21 there were exploit attempts but no confirmed breach, and CISA had not observed exploitation when it published its alert.

My read: assume scanning is happening against your internet-facing PHP now, and do not wait for a confirmed-breach headline before acting.

On scale, Cyber Security News cites a VirusTotal estimate of more than 5.1 million visible PHP hosts. That is an estimate of exposed hosts, not a count of vulnerable or compromised servers.

How to Verify Your PHP Version (Correctly)

A common mistake: running php -v checks the command-line binary only. Your PHP-FPM service or Apache module may be a different build. Check each runtime that actually serves traffic.

php -v
php-fpm -v
apachectl -M | grep -i php

What it does: Shows the CLI version, the FPM version (the binary name may be versioned, such as php-fpm8.3), and whether Apache loads a PHP module.
When to use it: At the start of triage, on every web host.
Expected output: A version string. Compare it to the fixed versions in the table above.

On distributions that backport fixes, the version number may look old even when the fix is present. Check the package changelog instead:

# Debian/Ubuntu
apt changelog php8.2-fpm | grep -i "CVE-2026-10961"

# RHEL/Alma/Rocky
rpm -q --changelog php | grep -i "CVE-2026-10961"

What it does: Searches the vendor changelog for the PHP2Shell CVE prefix. Adjust the package name to your install.
Expected output: A matching changelog line if the vendor has shipped the fix. No match does not prove you are vulnerable, so confirm with your vendor's security tracker.

Emergency Patch Management: A Practical Order of Operations

Teams that handle this well rarely have better tools. They have an inventory and a decision path. Here is the order I would work in.

1. Find every PHP runtime. Include forgotten hosts, containers, staging servers that face the internet, and vendor appliances that bundle PHP.
2. Rank by exposure. Internet-facing mod_php servers first, since that is where the advisory shows the clearest demonstrated risk.
3. Patch to the fixed release for your branch, or the vendor-backported package if you are on a distro-supported older version.
4. Restart workers. The PHP project says to restart PHP workers after upgrading. An updated package with old workers still running is not patched in practice.
5. Verify each pool and service, not just the package manager output.
6. Rebuild container images and redeploy, rather than patching inside running containers.

Managed hosting can shortcut some of this. Automattic said sites on WordPress.com, WordPress VIP, WP Cloud, and Pressable were already protected, so no customer action was needed there. Check your own provider's statement rather than assuming.

Temporary Mitigations (and Their Limits)

The PHP project says updating is the complete mitigation. If you truly cannot patch immediately, the advisory lists partial measures. None replace the update, and PHP core developer Gina Peter Banyard warned that no mitigation fully blocks potential attacks.

• Memory limit setting: the advisory names memory_limit=-1 as a primary step for CVE-2026-109618, ideally set so applications cannot override it (for example, php_admin_value in an FPM pool or Apache config). Be aware this removes a safety limit, so it trades one risk for another, such as resource exhaustion. Use it briefly.
• Frontend request limits: cap request body size and multipart inputs at your reverse proxy or load balancer.
• Avoid RLIMIT_AS and RLIMIT_DATA: the advisory warns these can cause allocation failures on the vulnerable path.
• PHP 8.5 only: setting fatal_error_backtraces=0 and restarting every worker removes one confirmed producer of stale state for CVE-2026-109619.

One workaround you may have seen circulated before the patch was disabling session upload progress. Security firms later walked back the idea that it fully mitigates PHP2Shell, and the advisory treats it as reducing exposure to one demonstrated path only. Do not rely on it.

WAF Protection as a Stopgap

A web application firewall can buy time, but it is not a patch. Cloudflare said it deployed managed WAF rules for known exploitation methods, available on all plans including free, and called them a stopgap only. If you sit behind a WAF vendor, confirm which rules are live and whether they are in block mode rather than log-only.

Be realistic about what this covers. The PHP2Shell flaws involve malformed or oversized multipart requests, and attackers adapt. A WAF rule tuned to known patterns will lag behind new variations, which is exactly why Cloudflare said it was updating mitigations as new vectors showed up.

Detection: What a SOC Should Hunt For

The Hacker News suggested watching what PHP starts. That is the most practical idea I have seen so far, because it does not depend on knowing the exact request pattern.

1. Unusual child processes from web workers

Your web server processes should almost never launch shells, interpreters, or download utilities. Alert when php-fpm, php-cgi, httpd, or apache2 is the parent of sh, bash, curl, wget, python, or similar.

ps -eo pid,ppid,user,args --forest | grep -E "php-fpm|php-cgi|apache2|httpd" -A3

What it does: Prints a process tree so you can see what your web workers have spawned.
When to use it: As a quick point-in-time check on a suspect host. For ongoing coverage, build the same logic into your EDR or auditd rules.
Expected output: Worker processes with no unexpected children. Some apps legitimately shell out (image processing, PDF tools), so baseline first.

2. Crashes and memory errors

Because the flaws involve memory handling, failed attempts may leave crash traces.

journalctl -k | grep -i segfault
grep -i "segfault\|Allowed memory size\|out of memory" /var/log/apache2/error.log /var/log/php*-fpm.log

What it does: Searches kernel and PHP/web server logs for crash and memory-exhaustion messages. Log paths vary by distribution.
Expected output: Ideally nothing new. A cluster of segfaults around the disclosure window deserves investigation. Note that clean logs do not prove safety, as Cyber Security News also cautions.

3. Request-level signals

Review web logs for unusually large or malformed POST requests to upload-style endpoints, especially multipart requests with oversized header sets or an abnormal number of empty file fields, plus bursts of 500 errors from a single source. Those match the conditions described in the PHP advisory. Treat them as leads, not proof.

4. Post-compromise indicators

If you suspect a hit, look for new or modified files in web-writable directories, unexpected outbound connections from the web tier, new cron jobs or user accounts, and credentials in config files that may need rotating. Remember the code would run with the web worker's privileges, so scope the blast radius by what that account can reach.

Expert Tips

• Do not trust the package manager alone. Confirm the running process was started after the update.
• Check non-obvious PHP. Appliances, admin panels, monitoring tools, and old marketing microsites often bundle PHP and rarely appear in asset inventories.
• Reduce the blast radius. Run web workers with minimal privileges, restrict outbound traffic from the web tier, and separate secrets from the web root. This helps against the next runtime bug too.

• Document the response. For HIPAA, PCI, or SOC 2 environments, record when you identified exposure, what you changed, and how you verified it. Auditors and cyber insurance questionnaires increasingly ask about patch timelines for critical vulnerabilities.
• Brief leadership with facts, not alarm. The honest message is: critical, patch available, exploitation attempts reported, here is our inventory status and ETA.

Related Cybersecurity Topics You Should Explore

• FortiSIEM CVE-2026-106173: Public PoC Drops, Patch Now
  
• Linux renice Command: 54 Examples to Control CPU Priority
  
• SBI Data Breach Claim: What's Real and What's Not
  
• Linux nice Command: 30 Examples to Protect Your Server CPU
  
• iOS 27.0.1 Untethered Jailbreak Explained: Risk and Fixes
  
• Nextcloud Servers Backdoored: Collabora Flaw CVE-2026-110447
  
• Linux killall Command: 31 Examples & Safe Usage Cheat Sheet

FAQ

What is PHP2Shell?

It is the name researchers gave to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. The name is not PHP's own. Both are described as allowing unauthenticated remote code execution.

What PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. SecurityWeek also reported minimal backports for 7.4, 8.0, and 8.1, and some Linux distributions may backport fixes to their packaged versions.

How severe are the flaws?

The PHP project rates both 9.2 out of 10 under CVSS 4.0. Some early reports cited 10.0, but that figure did not come from PHP.

Does a WAF fully protect me?

No. A WAF can reduce risk, and Cloudflare called its own rules a stopgap. The PHP project says updating is the only complete fix.

Do I need to restart anything after patching?

Yes. Restart PHP workers and confirm that every web-facing pool and service is on the patched version. Updating the CLI package alone may not update PHP-FPM or an Apache module.

Is WordPress affected?

WordPress runs on PHP, so a vulnerable PHP runtime underneath it matters. The issue is in the runtime, not WordPress itself. Managed hosts such as WordPress.com said they were already protected, but self-hosted sites must update their own PHP.

Are there confirmed breaches?

As of the reporting reviewed for this article, exploitation attempts were reported, and some outlets noted no confirmed successful compromise. This may change, so check current advisories.

Conclusion

PHP2Shell is a reminder that the most dangerous bugs are often in the layer everyone trusts and nobody inventories. The fix is straightforward: update, restart, and verify. The hard part is knowing where PHP actually runs.

If this helped, share it with whoever owns your web servers, and drop a comment with how your team is handling the rollout. Subscribe for more practical, SOC-focused breakdowns of new vulnerabilities.