← Back to blog

PHP2Shell (CVE-2026-109618, CVE-2026-109619): what is affected, and how do you stay protected until you update PHP?

On 21 October, PHP released emergency fixes for two critical vulnerabilities that have been dubbed PHP2Shell. Both allow unauthenticated remote code execution (RCE) and affect almost every PHP version that serves web requests, from 5.4 to 8.5. Details leaked before the official disclosure, and the first exploitation attempts were observed four days before the fixes shipped.

In this article: what is affected, how to check your servers quickly, what to configure if you cannot update today, and whether a WAF protects you.

1. What is PHP2Shell?

These are two memory-management bugs in PHP itself, not in a plugin or an application [1][2]:

The key point: the attack happens before your application code even runs. That is why updating WordPress, Laravel or other plugins does not help here; you need to update PHP itself. The second vulnerability also leaks PHP process memory, which may contain passwords, session tokens and API keys.

The vulnerabilities were found and reported by researchers from Wiz, Calif.io, OpenAI and Quarkslab [1][2].

2. How did it unfold?

• 19 August – the first bug is found; PHP is notified on 24 August.
• 17 October – Amazon sees the first exploitation attempts in its honeypots, four days before the fixes [15].
• 20 October – details leak on social media; PHP publishes a pre-announcement and CERT-EU issues a warning.
• 21 October, 03:02 UTC – Cloudflare enables WAF rules for all customers, including the free plan [3].
• 21 October, 14:00 UTC – PHP releases the fixes. On the same day, honeypots record exploitation of both vulnerabilities.
• 23 October – PHP announces another related vulnerability (CVE-2026-115560) that the 21 October releases do not fix. There is no fix for it yet [16].

According to Qualys, only about 199,000 of the 156 million PHP installations it can see were updated in the first 12 hours, and 71% of them run unsupported PHP branches [4].

3. Is my website vulnerable?

If your website runs on PHP and the version is lower than the one listed in the table, yes [1][2].

Every way PHP serves web requests is affected: Apache mod_php, PHP-FPM, php-cgi, LiteSpeed, FrankenPHP. Apache mod_php is the most urgent, because the attack is simplest there. With PHP-FPM, success depends on the configuration, but that is no reason to wait [5].

How to check:

php -v                       # CLI version (may differ from the web server!)
php-fpm -v                   # FPM version

The most reliable method is to create a temporary page with phpinfo() or look at the X-Powered-By header, because the CLI and the web server may use different PHP builds. In Linux distribution packages (Debian, Ubuntu, RHEL), the fix is often backported without changing the version number, so check your distribution's security advisory, not just the number.

If your website is hosted with a provider, ask them directly whether PHP has been updated to a fixed version, and when.

4. What should you do now?

1. Update PHP

This is the only reliable fix. The PHP team states clearly that no setting fully removes the vulnerabilities [1][2]. After updating, restart all PHP processes (FPM, Apache); otherwise old processes will keep running the old version.

2. If you cannot update today

PHP recommends the following temporary settings. They must be set in php.ini, the FPM pool or the web server configuration, not via ini_set() or .user.ini [1][2]:

; CVE-2026-109619: disable session upload progress
; (recommended to keep it disabled after updating too, if you do not use it)
session.upload_progress.enabled = Off

; PHP 8.5 only
fatal_error_backtraces = Off

; CVE-2026-109618: reduce the request size
post_max_size = 8M            ; 32M if the site has file uploads
upload_max_filesize = 6M      ; less than post_max_size
expose_php = Off

In addition:

• limit the request size on the web server or proxy and block multipart/form-data if the site has no file uploads;
• PHP-FPM: if performance allows, set pm.max_requests = 1 (every request runs in a new process, so the second vulnerability no longer has a "next" request to abuse);
• enforce the memory limit through a container / cgroup limit, not through RLIMIT_AS;
• eliminate errors that a visitor can trigger (fatal errors, timeouts), as well as .htaccess / php_value settings that generate warnings;
• anything you cannot update quickly should be taken off the internet (VPN, IP allowlisting) or isolated.

PHP also mentions memory_limit = -1 as a temporary mitigation for the first vulnerability, but it increases the risk of the server hanging when it runs out of memory, so only use it together with a cgroup limit.

3. Check whether you have been attacked

Attempts began on 17 October, so review your logs from that date onwards. Indicators mentioned by security researchers [5][6]:

• multipart/form-data POST requests containing a PHP_SESSION_UPLOAD_PROGRESS field from unfamiliar addresses;
• very long or unusual PHPSESSID cookies;
• PHP memory-limit errors at the start of a request and bursts of 500 responses;
• new or modified .php files, unknown processes, outbound connections from the server.

If you see suspicious indicators, updating alone is not enough: rotate passwords and API keys that may have been in PHP memory, and check that no web shells were left on the server.

5. WAFs and F5 BIG-IP (K000163821, K000163878): are you protected?

Partly, and this is a good example of why a WAF buys you time, not a fix.

Is F5 BIG-IP itself vulnerable?

Yes. The BIG-IP management interface (Configuration utility) and APM use PHP, so F5 has confirmed that the appliances themselves are vulnerable [7]:

Not affected: BIG-IQ, F5OS, BIG-IP Next, NGINX, F5 Distributed Cloud.

If you are still on 17.5.1.10 or 17.1.3.6, F5 also offers engineering hotfixes (Hotfix-BIGIP-17.5.1.10.0.37.35-ENG, Hotfix-BIGIP-17.1.3.6.0.9.20-ENG, from MyF5 Downloads). They do not go through full QA, so F5 provides them without warranty [7].

Does your scanner still report PHP 5.4.45 on BIG-IP 17.5.1.11?

That is expected. On fixed BIG-IP versions the PHP version number did not change: F5 backported both fixes into the PHP 5.4.45 build it ships. You can confirm the fix from the BIG-IP command line [7]:

php --version          # PHP 5.4.45 (cli) (built: Oct 23 2026 ...)
rpm -q php --changelog | grep CVE-2026-109618

Until you have updated, F5 recommends:

• creating /etc/php.ini.d/K000163821.ini with the settings recommended by PHP (memory_limit = -1, post_max_size = 8M, upload_max_filesize = 7M, session.upload_progress.enabled = 0) and restarting httpd (on APM, also httpd_sam, which may terminate webtop sessions). The settings do not survive a TMOS upgrade, and in an HA group they must be repeated on every device;
• closing the management interface to untrusted networks: set Port Lockdown on self IPs to Allow None or Allow Custom without port 443, and allow access to the management interface only from trusted addresses.

What else should you configure in BIG-IP Advanced WAF / ASM?

Beyond signatures, F5 suggests policy settings that reduce the attack surface but, in F5's own words, do not replace a PHP update [7]:

• if the application does not need file uploads, disallow multipart content (Header-Based Content Profiles → Disallow);
• limit the POST data length and the total request length (F5 recommends up to 8 MB, because the default WAF buffer is 10 MB);
• enable HTTP protocol compliance checks: limits on the number of parameters and headers, blocking of malformed multipart requests, multiple Content-Length headers, and chunked encoding combined with Content-Length;
• if session upload progress is not used, block the PHP_SESSION_UPLOAD_PROGRESS parameter (or the name set in session.upload_progress.name) with a regular expression that rejects all values;
• switch the policy to Blocking, remove staging exceptions and make sure the server cannot be reached by bypassing BIG-IP.

Why isn't a WAF enough?

• Attackers modify their requests to evade the rules; Cloudflare is already seeing this and keeps updating its rules [3].
• A WAF only protects traffic that passes through it. If the server can also be reached directly (direct IP, another domain, the internal network), the WAF will not help.
• CVE-2026-115560 (23 October; F5 tracks it in K000163878 [8]) works even against the updated PHP 8.5.12, and there is no fix yet: PHP promises one in the next regular release [16]. It only affects applications that configure the php_binary or php_serialize session serialisation handler and switch it to php via ini_set() before session_start() [14][16]. The existing Cloudflare rule stops it as long as the default session.upload_progress.name has not been changed [3]. The mitigation is the same: session.upload_progress.enabled = Off.

6. Why aren't patches alone enough?

PHP2Shell illustrates three things that will recur with other vulnerabilities:

1. Exploitation started before the fixes. No patching schedule protects against that.
2. Even for those who updated on time, a new related vulnerability appeared two days later.
3. Most organisations need days or weeks to update all of their servers.

Security therefore has to rest not on a single layer but on several layers that cover for each other:

• a cloud WAF (e.g. Cloudflare) – fast virtual patching and DDoS absorption;
• a WAF in front of the application (BIG-IP, Coraza) – rules tailored to your specific application, and protection if someone bypasses the cloud layer;
• egress filtering – even if RCE succeeds, the server cannot download malicious code or exfiltrate data;
• PHP and server hardening, segmentation and log monitoring.

We will describe how to build such an architecture in practice, with BIG-IP and Coraza examples, in a follow-up article. For more on what Cloudflare can do, see the article "Cloudflare WAF: nemokamas planas, taisyklės ir kada jo neužtenka" (in Lithuanian).

Frequently asked questions

Does updating WordPress plugins protect against PHP2Shell?

No. The vulnerabilities are in PHP itself, so you need to update the PHP version on the server (or ask your hosting provider to do it).

Does the Cloudflare free plan protect against PHP2Shell?

Since 21 October, Cloudflare has been blocking known attack variants on the free plan as well [3]. This reduces the risk but does not replace a PHP update: attackers modify their requests, and the server may also be reachable in a way that bypasses Cloudflare.

Is PHP-FPM vulnerable?

Yes, although exploitation is harder than with Apache mod_php and success depends on the configuration. You need to update in every case.

How do I know whether my PHP is already patched?

Check the version used by the web server (phpinfo()) and compare it with the table of fixed versions. If PHP comes from a Linux distribution package, check the distribution's security advisory: the fix may be backported without changing the version number.

What should I do if I run PHP 7.4 or older?

For the 7.4–8.1 branches there is only the patch code or distribution / LTS vendor packages; for 7.3 and older there is nothing. Until you move to a supported version, restrict access from the internet and apply the temporary settings from this article.

Sources

1. PHP — GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
2. PHP — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
3. Cloudflare — Cloudflare deploys protections against php2shell vulnerability
4. Qualys — PHP2Shell: Find, Mitigate, and Patch Now
5. watchTowr — PHP2Shell FAQ
6. SOCRadar — PHP2Shell (CVE-2026-109618 & CVE-2026-109619)
7. F5 — K000163821: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619 (updated 2026-10-30)
8. F5 — K000163878: PHP vulnerability CVE-2026-115560
9. AWS — Using AWS WAF to apply mitigations for PHP2Shell
10. Imunify360 — What Imunify360 Blocks and What Needs the PHP Update
11. OWASP CRS — PR #4893 (php2shell PoC User-Agent)
12. OWASP CRS — PR #4902 (953130)
13. frehi.be — PHP2Shell: mitigating with CRS and AppArmor before the patch
14. Astra — CVE-2026-115560
15. AWS — Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot
16. PHP — php.net announcement on CVE-2026-115560 (2026-10-23)