PHP2Shell: What It Means for Your Websites, and How Nexusguard Is Helping

You may have seen news this week about a pair of serious security flaws in PHP, the software that runs a large share of websites worldwide — including WordPress, online stores, and many custom business applications.

‍

On 21 October 2026, the PHP project issued emergency updates for two issues known together as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both are rated Critical. In plain terms: someone on the internet, without a username or password, may be able to run their own code on a vulnerable web server. That is as serious as it sounds. It does not mean every PHP website is already compromised, and it does not mean Nexusguard’s Application Protection WAF is itself at risk.

‍

Here is what the issue is, whether you are affected, what we are doing, and what you should do next.

‍

What it is

Think of PHP as the engine behind many websites. When a visitor loads a page, fills in a form, or uploads a file, PHP is often the software that receives that request and turns it into a response.

‍

PHP2Shell is not a bug in one plugin or one brand of website builder. It is in PHP itself — in how the engine handles incoming web requests, especially the kind of request browsers use for file uploads. The problem can show up before your own website code even starts. Updating a theme or a plugin is not enough. The PHP software on the server needs to be updated.

‍

There are two related flaws:

‍

When PHP runs out of memory. If PHP is pushed past its memory limit while handling a request, it can fail in an unsafe way. Instead of simply stopping, it can leave the server in a state an attacker can take advantage of. Public advisories confirm this can lead to a full takeover of the web server.

‍

When leftover data is reused. Website servers often reuse the same PHP process for many visitors, one after another. If one request leaves that process in a messy state, the next request on the same process can be mishandled. Researchers have shown that this, too, can lead to a takeover. One confirmed trigger involves a built-in PHP feature that tracks file-upload progress. That feature is on by default, even if your application never asked for it.

‍

Public reporting has described attackers using these issues before they were announced. That is a reason to treat the update as urgent. It is not proof that your particular website was hit.

‍

Are you affected?

You may be affected if any of your public websites, APIs, or customer portals run PHP and have not yet received the 21 October emergency update.

‍

You are on the right path if:

• your sites do not use PHP at all, or
• your hosting provider, IT team, or managed-service partner has already applied the patched PHP versions (8.5.12, 8.4.27, 8.3.36, or 8.2.35) and restarted PHP, or applied your operating-system vendor’s security update.

‍

PHP 7.4 through 8.1 receive only minimal source-level backports. PHP 7.3 and older will not be fixed. If you are on one of those versions, you need a plan to move to a supported PHP branch — a small patch is not enough.

‍

If you are unsure, that is common. Many organisations run PHP without thinking about it — it is simply “the website.” Ask whoever looks after your hosting, WordPress, or application servers.

‍

Is Nexusguard affected?

Nexusguard Application Protection WAF is not impacted. Our WAF is not PHP. It does not run your website’s PHP code, and these flaws are not a defect in the Nexusguard platform.

‍

If you run PHP on your own servers (or your hosting provider’s servers) behind Nexusguard, those servers can still be at risk until PHP is updated. That is an origin-software problem — the same kind of “please patch the application” issue we see with other widely used web software. Updating PHP is the primary action.

‍

This is also not a DDoS flood. Nexusguard DDoS protection is not the path an attacker uses for PHP2Shell. The risk is to the application runtime on the web server, not to network capacity.

‍

How we are helping

We know patching a fleet of websites takes time: you have to find where PHP runs, plan a maintenance window, and test. While you do that, you should not be unprotected.

‍

We are rolling out WAF rules across the Nexusguard Application Protection platform to detect exploitation attempts targeting CVE-2026-109618 and CVE-2026-109619. These rules give you an extra layer of visibility and protection while you patch.

‍

Please treat them as a seatbelt, not as the repair. They do not replace upgrading PHP. Patching your servers remains the only complete fix. Some of the PHP2Shell paths live inside the server itself and cannot be fully closed by a web application firewall, no matter how well it is tuned.

‍

Network-level protection also only helps traffic that actually passes through it. If your origin servers still accept web traffic straight from the internet, an attacker can go around Nexusguard. Please make sure those servers accept web traffic only from your protection service.

‍

If you have questions about your exposure, or need help reviewing suspicious traffic, please contact our support team. We are here to walk through this with you — you do not need to be a security engineer to ask.

‍

What you should do

Even if you are not the person who logs into the server, give this list to your IT team, hosting provider, or website partner. Include WordPress, Magento, and any custom web applications that are reachable from the internet.

‍

1. Upgrade PHP immediately. The fixed releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. If you use your operating-system vendor’s PHP packages, apply that vendor’s security update. Do not wait for a quieter week if the sites are public.

2. Restart all PHP workers after upgrading. That means PHP-FPM pools, Apache, and any long-running PHP processes. Installing the package is not enough. The fix does not take effect until the old processes are gone.

3. Plan an upgrade if you run end-of-life PHP. PHP 7.4 through 8.1 receive only minimal source-level backports, and PHP 7.3 and older will not be fixed. If you are on one of these versions, move to a supported branch as soon as possible.

4. Apply interim mitigations if you cannot patch right away. These reduce risk. They do not replace patching. Ask your administrator to make the changes in the main server or PHP-FPM pool configuration and then restart PHP. Settings made through ini_set() or .user.ini do not protect against these flaws.

• Set session.upload_progress.enabled = 0.
• Lower post_max_size to the smallest value your application can work with.
• Lock the memory limit so applications cannot override it — for example
  ‍php_admin_value[memory_limit] in the PHP-FPM pool config, or
  ‍php_admin_value memory_limit in Apache.
• On PHP 8.5, set fatal_error_backtraces = 0.

5. Review your logs. Look for unusual POST requests with multipart/form-data bodies, especially ones containing a PHP_SESSION_UPLOAD_PROGRESS field together with a PHPSESSID session cookie. Also look for unexpected PHP worker crashes or restarts. We recommend reviewing activity from 17 October 2026 onward.

6. Do not leave your origin servers directly exposed. Network-level protection only helps traffic that passes through it. Make sure your origin servers accept web traffic only from your protection service, not straight from the internet.

7. Call us if you want help. Contact our support team with questions about exposure or to review unusual traffic. You do not have to diagnose this alone.
   ‍

Closing

PHP2Shell is urgent for websites still running unpatched PHP. It is not a Nexusguard WAF-engine problem, and we are adding extra detection while customers update. The lasting fix is still the PHP upgrade.

‍

We are monitoring the situation and will revise this guidance if the facts change.
‍

Sources

• PHP project advisory for CVE-2026-109618
• PHP project advisory for CVE-2026-109619
• AWS Security Blog on PHP2Shell mitigations (21 October 2026)
• AWS Security Bulletin 2026-143-AWS
  ‍

Publication checklist

• Informs, educates, states impact, and states what to do
• Advisory checklist completed and consistent with this draft
• No exploit recipes or payloads beyond what is already public
• No customer names, unpublished topology, liability caps, or SLA credit tables
• Latest-platform disclaimer present
• Written for a general customer audience, not only technical readers
• Security/Threat Research: pending
• Product / Legal / classification / Communications (Donny for this documentation phase): pending