CybersecurityServersWeb

PHP under attack: CVE-2026-109618 and CVE-2026-109619 (php2shell), what to do right now before your server gets taken

21 October 2026

Today, Wednesday 21 October 2026, at 14:00 UTC the PHP team ships an emergency security release for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. If you run a website or an application on PHP, you have a few hours to get ready. That is not a figure of speech: e-commerce security researchers expect the first mass attacks within fifteen minutes of the fixes going public.

What makes this different from the usual plugin bugs is that the problem is not in your site's code but in the PHP interpreter itself. An up-to-date WordPress, trusted plugins, well-written code: if the PHP underneath is vulnerable, none of that is enough.

Below you will find what we actually know (kept apart from what is circulating without confirmation), who is at risk and, above all, what to do before and after 14:00 UTC.

What is confirmed and what is not

In a story like this, the first job is to separate facts from rumours.

Confirmed:

On 20 October the PHP project announced on its website a security release for two critical vulnerabilities, both scored 9.2 on CVSS v4.0, scheduled for 21 October at 14:00 UTC. The notice asks all users to "prepare now" and reserves the right to release earlier if details go public.
CERT-EU published advisory 2026-018: based on the score, the flaws could allow unauthenticated remote code execution. Its advice is to get ready to patch immediately and, where that is not possible, consider isolating internet-facing applications from public networks until the fix is installed.
Security firm watchTowr says it has reproduced exploitation of CVE-2026-109618 and will not share details before the patch.
So far no real-world attacks using these flaws have been reported.

Not confirmed:

The affected versions. CERT-EU writes that they "could" include everything from PHP 5 onwards; other sources say PHP 5.4 and later. The PHP project has not said yet.
The technical cause. Unofficial reconstructions point to how PHP handles multipart/form-data requests (the ones used by forms and file uploads), and specifically to the session upload progress mechanism, which PHP uses to track upload progress and which is enabled by default.
The name php2shell is not official: it is the one used by researchers and by the proof-of-concept tools shared online.

The news came out earlier than planned: the embargo broke on 20 October through a Hacker News post that was later deleted. That is why the PHP project brought its announcement forward.

Why it is so serious

On a typical web server, the browser's request reaches Apache or Nginx, which hands it to the PHP interpreter (often through PHP-FPM). PHP reads the incoming data, prepares it for the application, runs the code and returns the page.

Everything rests on one simple principle: what comes from outside (a form field, a cookie, an uploaded file) must stay data and never become instructions. A Remote Code Execution (RCE) vulnerability is exactly the breaking of that separation.

If the hypotheses are right, here the break happens while PHP is still parsing the request, before your code even runs. That explains three things:

Your CMS does not matter. The demos that circulated mention WordPress, Drupal and Magento; Sansec also lists Shopware and WooCommerce. The point is that the problem sits below the application.
You cannot fix it in your site's code. As Sansec puts it, you cannot fix it from within your store's codebase: PHP has to be updated at the infrastructure level.
One request is enough. If exploitation needs no authentication, any PHP server reachable from the internet is a target, and automated scanning of millions of sites is a matter of hours.

What happens next? The attacker runs code with the permissions of the PHP process (for example the www-data user). That is not root, but it is often enough: they can read the configuration file holding the database credentials, change pages, drop a web shell to come back whenever they like, inject card skimmers into online shops, and use the server to attack other systems on the internal network.

Who is exposed

If the preliminary reports are confirmed, practically anyone running PHP. With one important distinction:

PHP 8.2, 8.3, 8.4 and 8.5 are still supported by the project and will get the official patch.
PHP 8.1 and older are out of support: there will be no official fix. You depend on a backport from your distribution (Debian LTS, Red Hat, extended support vendors) or from your hosting provider. Otherwise, migration is the only way out.

And watch out for where PHP hides: staging sites, old internal back-office tools, admin panels, forgotten phpMyAdmin installs, containers whose images were never rebuilt. Those are the ones nobody updates and the ones an attacker finds first.

What to do now, before the patch

1. Take a (real) inventory

Knowing your WordPress version is not enough: you need to know which PHP version is actually serving your pages. Running php -v in a terminal shows the command-line version, which can differ from PHP-FPM or the Apache module.

php -v                                   # CLI version
ls /etc/php/                             # installed versions (Debian/Ubuntu)
systemctl list-units 'php*-fpm*'         # which FPM services are running

For each site, the reliable check is from the web: a temporary page containing <?php phpinfo(); that you delete right afterwards, or the X-Powered-By header if it is enabled. List everything: production, staging, internal tools, containers.

2. Apply the temporary mitigation

The most widely cited measure (Sansec, GMO Flatt Security and others) is to turn off upload progress tracking. Uploads keep working; only progress bars built on this feature stop, and almost nobody uses them.

In php.ini or a file under conf.d:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Or in the PHP-FPM pool (for example /etc/php/8.4/fpm/pool.d/www.conf):

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Then reload (systemctl reload php8.4-fpm, or restart Apache if you use mod_php) and check from the web that the value shows Off: the command line reads a different configuration file.

On shared hosting without access to php.ini: with mod_php use .htaccess with php_flag session.upload_progress.enabled off; with CGI/FastCGI use a .user.ini file (it can take up to 5 minutes to be picked up).

Be honest about what this is worth: it is not officially confirmed. According to some researchers it blocks only one of the two flaws, while the other reportedly sits in the multipart parser. It reduces the risk for a few hours; it is not a solution.

3. Reduce your exposure

This is CERT-EU's advice, and it works even without knowing the details of the flaw:

take off the internet whatever does not belong there: staging, admin areas, phpMyAdmin, internal tools. Put them behind a VPN or restrict them by IP;
if an application is not essential this afternoon, consider switching it off until the update;
if you have a WAF or reverse proxy, prepare rules for multipart/form-data requests to endpoints that never receive uploads. Carefully: blanket blocking breaks legitimate forms and features and does not guarantee full coverage.

4. Get the update path ready

Do you already know where the new version will come from? Your distribution's repositories (the Debian or Ubuntu security team may publish a few hours after the PHP project), third-party repositories such as Ondřej Surý's, your hosting control panel, official Docker images. If a provider manages your server, call them this morning and ask when they will install the patch.

5. Back up and watch the logs

A recent backup of files and database is useful whatever happens. And start watching traffic now: unusual multipart POST requests to pages that never receive uploads, odd PHP errors, PHP-FPM child processes spawning shells.

What to do after 14:00 UTC

Update as soon as the fixed version is available through your channel (distribution, repository, hosting, Docker image).
Restart PHP-FPM (or Apache with mod_php). Running processes keep using the old code until they are restarted.
Rebuild your containers: updating the base image is useless if the container still runs the old one.
Check from the web that the version being served is the fixed one, site by site.
Make sure you have not already been hit, especially if you updated late:

# PHP files created or modified in the last 2 days inside the site
find /var/www -name '*.php' -mtime -2 -ls
# PHP files in upload folders (there should be none)
find /var/www -path '*upload*' -name '*.php*' -ls
# cron jobs added to the web server user
crontab -u www-data -l

If you find anything suspicious, do not just delete it: change the database passwords and API keys stored in your configuration files, because you must assume they have been read.

Once the temporary mitigation is no longer needed, decide calmly whether to re-enable session.upload_progress. You probably did not need it before and will not need it afterwards.

If you are stuck on PHP 7 or 8.0/8.1

This is the most awkward case, and it is more common than people think: business tools written ten years ago, plugins that "don't work" on newer versions, servers nobody wants to touch.

There are three ways out: a backport from your distribution or an extended support vendor, if one exists; full isolation of the application (no internet access, VPN only); migration to a supported version. What you cannot do is leave the server exposed and hope.

The php2shell lesson

This story repeats something security people have been saying for years: updating the application is not enough if the components underneath stay vulnerable. Interpreter, web server, libraries and operating system are all part of the attack surface.

And it adds another: when fifteen minutes separate the release of a patch from the first attacks, security cannot depend only on how fast you update. Applications that do not need to be public should not be reachable by anyone. That is the principle we built ZTAG on: filter and authenticate traffic before it reaches the application, so that a flaw in the interpreter is not reachable by the first scanner that comes along.

For today, though, there is only one priority: know where PHP runs, mitigate now, update at 14:00 UTC.

Written on the morning of 21 October 2026, before the fixes were released. Affected versions and technical details will be clarified by the PHP project's official release notes.