PHP2Shell (CVE-2026-109618 and CVE-2026-109619): is your website affected, and how to fix it

On 21 October 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They let an attacker run commands on a web server with a single crafted request, without an account and without touching your site's own code.

If your website, shop or admin panel runs on PHP, and that includes most WordPress, WooCommerce, Laravel, Drupal and Magento sites, this is worth ten minutes of your time today.

Short version: update the PHP runtime that serves your site to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or your vendor's patched package), then restart PHP. Updating WordPress or your plugins does not fix this. The widely shared session.upload_progress.enabled=0 setting is not a complete fix.

Last checked: 24 October 2026. This is a fast-moving story; follow PHP's official advisories for changes.

What PHP2Shell is, in plain words

Both flaws are in the PHP engine itself, not in WordPress, Laravel or any plugin. That's what makes them unusual: a site with perfectly secure code is still exposed, because the attack happens while PHP is still reading the incoming request, before your application runs at all. Security researchers have shown that even a one-line "Hello World" page on a vulnerable PHP version can be attacked.

• CVE-2026-109618: when PHP runs out of memory partway through reading a form submission, it leaves half-built data behind, and its cleanup code later treats that data as valid. An attacker who shapes that leftover data can make the cleanup run a command.
• CVE-2026-109619: a PHP worker can carry stale data from one request into the next. Researchers confirmed command execution through this route as well, including via the upload-progress feature, which is on by default.

Both are rated 9.2 out of 10 (CVSS v4.0). Researchers also showed that an attacker can read memory from a PHP worker, which can include other visitors' session tokens, passwords and API keys, even without running a command.

They were found by Wiz Research, Calif and OpenAI's Codex Security team. Details leaked a day before the planned disclosure, so PHP released the fixes early.

Is it being exploited?

Exploitation attempts started before the patches shipped. AWS reported attempts as early as 17 October, Cloudflare saw attack traffic and attackers changing their payloads to get past its firewall rules, and watchTowr reported active exploitation attempts against both flaws on 21 October. At the time of writing, public reports hadn't confirmed a specific successful break-in, but several organisations took services offline as a precaution.

Treat this as urgent, not theoretical.

Which sites are affected?

Any server where PHP answers web requests, in any of these setups:

Affected versions go back to PHP 5.4. These are the first fixed releases:

PHP 8.2 itself reaches end of life on 31 December 2026, so if you're upgrading anyway, go to 8.3 or newer.

Not affected: sites with no PHP at all, such as a static site, or a Next.js or Node.js app. But if your Next.js front end talks to a PHP backend (for example headless WordPress), that backend server is affected.

How to check and fix it, by type of hosting

Shared hosting (cPanel, Hostinger, GoDaddy, Bluehost and similar)

You usually can't patch PHP yourself here. Your host does it.

1. Find your PHP version. In WordPress, go to Tools → Site Health → Info → Server. In cPanel, look for Select PHP Version or MultiPHP Manager.
2. Ask your host directly whether their PHP builds include the fixes for CVE-2026-109618 and CVE-2026-109619. Hosts often patch without changing the version number you see, so the version alone doesn't tell you.
3. If you're on PHP 7.4, 8.0 or 8.1, ask the host to move you to 8.3 or newer, and test your site afterwards. Older plugins sometimes need updating first.

A short message you can send:

Hi, my site [domain] runs on your PHP. Can you confirm the PHP version serving it includes the patches for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If not, when will it be patched?

WordPress, WooCommerce, Laravel and other PHP apps

Keep your app and plugins updated as always, but understand that this isn't an application bug. Updating WordPress, a plugin or Laravel does not update the PHP engine underneath. That comes from your host, your server's package manager or your container image.

VPS or dedicated server (Ubuntu, Debian, RHEL)

1. Check what actually serves your site. php -v on the command line can be a different build from the one PHP-FPM or Apache uses, so check the web runtime too (your control panel, or a temporary phpinfo() page that you delete straight after).
2. Update through your package manager and restart every PHP process:

# Debian / Ubuntu (package names vary, e.g. php8.3-fpm)
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # PHP-FPM
sudo systemctl restart apache2      # if you use mod_php

3. Distribution packages often carry the fix under an older-looking version number. Confirm the fix is in the package's changelog rather than trusting the version string:

apt changelog php8.3-fpm | grep -m1 CVE-2026-109618

Docker and Kubernetes

Rebuild your images on a patched PHP base image, redeploy, and make sure no old containers are still running. Also check images you didn't build yourself: some third-party apps bundle their own PHP.

If you can't patch today

PHP is clear that only updating fully fixes this. These steps reduce exposure while you arrange the update:

• Put a firewall in front of PHP. Cloudflare switched on protective rules for its customers before disclosure, but it also saw attackers changing payloads to get around them, so treat this as a stopgap.
• Limit request sizes at your web server or proxy, and keep post_max_size low.
• PHP's temporary guidance for CVE-2026-109618 is to enforce memory_limit=-1 at the administrator level, together with request-size limits in front of PHP and a memory limit on the container.
• For CVE-2026-109619: session.upload_progress.enabled=0, plus fatal_error_backtraces=0 on PHP 8.5, then restart every worker. This blocks the confirmed paths but not every variant, and does nothing for CVE-2026-109618.
• Restrict access to anything that doesn't need to be public, such as admin panels, staging sites and internal tools.

Signs you might have been attacked

If your server ran an unpatched PHP version while exposed to the internet, look back through your logs for:

• Unusually large form or multipart POST requests, followed by memory-limit errors or bursts of HTTP 500 responses.
• Oddly large PHPSESSID cookies in responses.
• PHP workers restarting without explanation.
• Shell commands or processes started by your web server user (for example www-data).

If you see any of these, assume secrets in memory may have leaked: rotate database passwords, API keys and admin passwords, invalidate active sessions, and check for new admin users or modified files.

After you patch

• The fix adds a new hard memory limit. Hitting it ends the process, so review memory_limit and post_max_size against what your site actually needs, and test uploads and large forms.
• PHP has since published an advisory for a related issue, CVE-2026-115560, in the session upload progress feature, which affects even the patched releases. It's due to be fixed in PHP's next regular release. Watch PHP's advisories and update again when that's out.

Running Next.js? Different bug, same month

If your site is built with Next.js, PHP2Shell doesn't apply, but there's a separate security release to install. On 14 October 2026, Next.js fixed:

• CVE-2026-96889, a critical remote code execution flaw in the Image Optimization API when SVG files are processed, through the sharp image library on Linux.
• A second critical remote code execution flaw in use cache functions that return typed arrays (Next.js 16).
• A high-severity denial-of-service issue affecting App Router apps that use Server Actions.

Upgrade to Next.js 16.4.1 or 15.5.28 or later, and make sure your lockfile resolves sharp to 0.35.5 or later. Running npm audit will flag both. More on hardening Server Actions in my security checklist.

FAQ

I updated WordPress and all my plugins. Am I safe?

Not from this. PHP2Shell is in the PHP engine, which your host or server provides. Check the PHP version and ask your host to confirm the patch.

Does a WordPress security plugin protect me?

A plugin runs inside your application, after PHP has already read the request. This attack happens before that point, so an in-app plugin can't block it. A firewall in front of the server can reduce the risk; only patching removes it.

My site is small. Would anyone really target it?

Attacks like this are automated: bots scan the whole internet for vulnerable servers, regardless of size. Security researchers estimate tens of millions of internet-facing PHP servers may be exposed.

How do I know the patch worked?

Confirm the version serving web requests (not just the command line) is a fixed release, or that your distribution's package changelog mentions both CVEs, and that every PHP process has been restarted since the update.

Sources

• Datadog Security Labs: PHP2Shell detection, analysis and remediation (opens in a new tab)
• The Hacker News: PHP issues emergency patches for PHP2Shell (opens in a new tab)
• Unit 42 threat brief: CVE-2026-109618 and CVE-2026-109619 (opens in a new tab)
• Cloudflare: protections against the php2shell vulnerability (opens in a new tab)
• Netlify: Next.js and React security release, October 2026 (opens in a new tab)

---

Not sure what your site runs on, or whether your host has patched it? I can check your setup, apply the fix or move you to a supported version. Get in touch.