PHP2Shell CVE-2026-109618: How to Patch PHP Now

Short answer: On 21 October 2026 the PHP project fixed two critical bugs that can let an attacker run code on your server without logging in, and both are rated CVSS v4.0 9.2. If your website, store or Laravel app runs on PHP, upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distribution's patched package) today, because exploitation attempts are already being seen.

By Mohamed Samy, senior Laravel/PHP backend developer (7 years). Published: 22 October 2026. Last updated: 22 October 2026.

---

I have patched a lot of PHP servers over the years, and most PHP security releases are the "update at your next maintenance window" kind. This one is not. The PHP team sent an advance warning on 20 October, published the fix on 21 October, and their own advisory title says "update now". Below is what happened, who is affected, and the exact steps I would follow on a client server this week.

What happened

Item	Details
Nickname	PHP2Shell (name used by Amazon, Tenable and others)
CVE IDs	CVE-2026-109618 (RCE via OOM corruption), CVE-2026-109619 (RCE via stale global state)
GitHub advisories	GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
Severity	Critical, CVSS v4.0 9.2 (both)
Authentication needed	None
Affected	PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, 8.5 before 8.5.12, plus all unsupported versions (8.1 and older)
Fixed in	8.2.35, 8.3.36, 8.4.27, 8.5.12 (released 21 Oct 2026)
Advance notice	php.net, 20 Oct 2026

In plain words:

• CVE-2026-109618: when PHP runs out of memory at the wrong moment while setting up a request, it can leave internal data half-built. The cleanup step then trusts that broken data. The advisory explains that a crafted multipart (file upload style) request can push PHP into that out-of-memory state, and on Apache with mod_php this happens before your application code even runs.
• CVE-2026-109619: some internal state from one request can survive after its memory is freed, and the next request handled by the same PHP worker can use it. With a carefully shaped memory layout, that becomes code execution.

You do not need to understand the internals. What matters for a business owner: an attacker who can send HTTP requests to your site may be able to take over the server.

Is it being exploited?

Yes, attempts are real. Amazon Threat Intelligence reported an exploitation attempt against its honeypots on 17 October, four days before disclosure, and says PHP2Shell "is now being broadly exploited in the wild". Tenable's FAQ cites Cloudflare and watchTowr seeing attacks and exploitation attempts. VulnCheck reported at least one attempt that failed. So treat this as active, and if your server was unpatched, Amazon recommends investigating from 17 October onward, not from the disclosure date.

Who is affected

According to the PHP advisory, all PHP installations serving web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest risk, with a demonstrated exploit.

Your setup	Affected?	What to do
Laravel app on a VPS (Nginx + PHP-FPM)	Yes	Upgrade the PHP package, restart FPM
WordPress or WooCommerce on shared hosting	Yes	Check PHP version in the panel; ask the host if it is not patched
cPanel / WHM server	Yes	Update EA-PHP packages, restart PHP-FPM / Apache
Plesk server	Yes	Update PHP components from Plesk updates
Docker images (php:8.x)	Yes	Pull the new base image and rebuild
PHP 8.1, 8.0, 7.4	Yes, no official release	Upgrade, or get backported packages from your distro or LTS vendor

Important: Laravel, WordPress or any framework update will not fix this. The bug is in the PHP engine itself, so the fix has to come from the PHP binary on the server.

Step 1: Check your PHP version

On a server with SSH:

php -v
php-fpm8.3 -v   # adjust to your version

Remember that the CLI and the web server can use different PHP versions. To see what the website actually uses, put a temporary file with <?php echo PHP_VERSION; in the web root, open it once, then delete it.

On shared hosting: cPanel shows it under MultiPHP Manager or Select PHP Version; Plesk shows it under Websites & Domains > PHP.

On Ubuntu/Debian you may see a version like 8.2.35-1~deb12u1 or a distro-patched build. Distributions often backport fixes without changing the main version, so check your distribution's security tracker. For example, Debian lists 8.2.35-1~deb12u1 (bookworm security) and 8.4.27-1~deb13u1 (trixie security) as fixed.

Step 2: Upgrade

Ubuntu/Debian VPS (typical Laravel setup)

sudo apt update
sudo apt install --only-upgrade 'php8.3*'   # use your version
sudo systemctl restart php8.3-fpm
sudo systemctl reload nginx
php -v

If you use the ondrej/php PPA or another repository, confirm the patched build is published there first. The PHP team specifically warned that the volunteer-run rpms.remirepo.net would not have updates on release day, and recommended distribution packages or building from source instead.

RHEL / AlmaLinux / Rocky

sudo dnf update 'php*'
sudo systemctl restart php-fpm

cPanel / WHM

Update EasyApache PHP packages (ea-php82, ea-php83 and so on) through WHM or yum/dnf update ea-php*, then restart PHP-FPM and Apache. Check cPanel's own announcements for the exact package versions.

Plesk

Go to Tools & Settings > Updates and install the latest PHP component updates, then check each domain's PHP handler version.

Docker

docker pull php:8.3-fpm   # your tag
docker compose build --no-cache && docker compose up -d

Laravel specifics

• No code change is required for the fix, but test your app after the upgrade: run your test suite, queue workers and scheduled jobs.
• Restart long-running PHP processes (php artisan queue:restart, Horizon, Octane, Reverb) so they load the new binary.
• If you deploy with Forge, Ploi or similar, update PHP through their panel and confirm the version afterwards.

Step 3: If you truly cannot upgrade today

The PHP advisory lists measures that reduce exposure but do not make an installation safe:

1. For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example php_admin_value in the FPM pool or Apache config). Lower post_max_size (8M if you have no uploads, 32M if you do) and keep upload_max_filesize below it. Enforce request size, field count, multipart part count, header count and nesting limits at the web server or proxy.
2. For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the FPM pool (not via ini_set() or .user.ini) and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0.
3. Use a container or cgroup memory limit as a boundary. The advisory warns not to use RLIMIT_AS or RLIMIT_DATA as a substitute.

Two notes from practice: memory_limit=-1 means a single bad request can eat a lot of RAM, so watch your server closely. And none of this replaces the upgrade.

Step 4: Check for signs of compromise

Because attempts started before the disclosure, I would also:

• Review access logs from 17 October for unusual multipart POST requests, especially ones containing PHP_SESSION_UPLOAD_PROGRESS (Amazon recommends looking for these).
• Look for new or modified PHP files in upload and cache folders, new cron entries and unexpected processes.
• Rotate secrets that live on the server (.env database passwords, API keys) if anything looks wrong.

FAQ

Is my site affected if I use Laravel?

Yes, if the server's PHP version is below the fixed releases. Laravel itself is not the problem; the PHP engine is.

My hosting company manages the server. Do I need to do anything?

Check the PHP version in your control panel and ask your host in writing whether they have deployed PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a patched distribution build.

I am on PHP 7.4 or 8.1. What now?

The PHP project no longer releases those versions. It published minimal source backports, and some distributions or LTS vendors provide patched packages, but the safe path is to move to a supported version.

Is changing php.ini enough?

No. The PHP team says only an update is a complete solution.

Does a WAF or Cloudflare protect me?

It can reduce risk. Cloudflare said it is updating its mitigations, but a WAF is not a substitute for patching.

Does this affect PHP 8.2 long-term?

PHP 8.2 receives security fixes only until 31 December 2026, according to php.net. Plan the move to 8.3 or newer now. See our PHP 8.2 end of life upgrade plan.

Sources

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now and Upcoming Critical PHP Security Release
• PHP 8 ChangeLog
• GitHub advisories: GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp
• NVD: CVE-2026-109618, CVE-2026-109619
• Debian security tracker: CVE-2026-109618
• Amazon Threat Intelligence (AWS Security Blog): PHP2Shell exploitation prior to public disclosure
• Tenable: php2shell FAQ

Need a second pair of eyes?

If you are not sure which PHP version your site runs, or you want someone to patch and check the server for you, the Golden Code cybersecurity team can help. Send us a message through the contact page.

---

About the author: Mohamed Samy is a senior backend developer at Golden Code with 7 years of experience building and maintaining Laravel and PHP systems.