PHP security update: patch php2shell before the next bugfix release

Is your PHP website safe right now? On 21 October 2026 the PHP project shipped a PHP security update: versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution. If your website, online store or internal system runs on PHP, update now and keep one extra setting off until PHP’s next regular bugfix release.

This article sums up what happened, which versions are safe, the steps to take this week, and how to check whether your server is really patched.

What happened: php2shell in brief

The two vulnerabilities are known as php2shell. According to Cloudflare, they were disclosed on 21 October 2026 by Calif.io, Wiz, OpenAI and Quarkslab. The PHP project published a security advisory the same day and strongly encouraged all PHP users to update immediately.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE via OOM corruption. Out-of-memory handling can interrupt PHP while internal request data is only partially initialized.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE via stale global state. Request-owned internal state can survive after its backing memory has been freed.

In plain words: under the wrong conditions, someone could run their own code on your server without logging in. That is why both bugs are rated critical.

Which PHP versions are safe?

If you run PHP 8.2 or newer, the fix is a regular update to the version in the table. For the older PHP 7.4, 8.0 and 8.1 branches, the PHP security team provided minimal source backports instead of new releases. Those help teams that build PHP from source. For most businesses, we suggest planning a move to a newer branch at the same time.

The follow-up advisory on 23 October

Two days later PHP published an informational advisory about session upload progress. PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect from an unlikely RCE vector. A full advisory for CVE-2026-115560 will be published with that release.

Cloudflare notes that this issue affects fully patched releases, including 8.5.12. So updating is not the end of the job this month: keep upload progress off until the next PHP release ships.

What to do before the next PHP bugfix release

1. 1Check the real PHP version on every server. Distribution packages on Debian, Ubuntu, RHEL or Alpine often backport fixes without changing the upstream version number, so php -v alone is not enough. Check the package changelog for CVE-2026-109618 and CVE-2026-109619.
2. 2Test the update on staging. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s patched package, then run through checkout, login and forms.
3. 3Update production, including every server, container and worker that runs PHP.
4. 4Set session.upload_progress.enabled=0 and restart every worker, so no old process keeps running with the old setting.
5. 5Watch for the next regular PHP release, which will fix CVE-2026-115560, and roll it out the same way.

If you cannot update today

PHP lists temporary mitigations, but says they only reduce exposure and do not make an installation safe. Updating is the only complete fix.

• 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 configuration.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker.

Is a WAF enough?

Cloudflare says its WAF, on free and paid plans, has protected sites by default since 21 October 03:02 UTC. Cloudflare also says customers should still patch PHP, because a WAF is defense in depth, not a replacement for the update.

What it means for your business

Many company websites, online stores and internal dashboards run on PHP through WordPress, Laravel or custom code. The framework does not change the answer here: the fix lives in the PHP runtime on the server. If a hosting provider manages that runtime, ask them which package is installed and whether it includes both CVE fixes. If your own team manages the server, this belongs on this week’s list.

Security updates rarely arrive on a convenient date. We saw the same pattern for JavaScript sites in how to update Next.js safely: the teams that recover fastest already have staging, backups and a tested update routine in place.

How Estontinc helps

Estontinc is a software house in Malang, Indonesia, with 100+ projects and 50+ clients over more than six years. For PHP websites and systems, we can:

• Audit PHP versions across your servers, containers and hosting, including distribution package changelogs.
• Patch with testing, on staging first and then production, as part of our web development service.
• Keep it maintained after launch with our maintenance service: bug fix and update, monitoring and backup, and small monthly improvements, with server work handled by our cloud and DevOps team.

We work under NDA, you own the source code, and we communicate in English, Indonesian or Japanese. Want a quick check of your PHP setup? Send the details through the contact page and we will reply within 24 hours.