PHP2Shell CVE-2026-109618: What to Do Right Now

PHP2Shell CVE-2026-109618: What to Do Right Now

The PHP group scheduled a security release for 14:00 UTC today, 21 October 2026. Panic is moving faster than verified information.

When high-severity runtime flaws leak into public discussion before official release notes drop, engineering teams end up chasing ghost configurations or breaking production with unvetted workarounds. This guide documents what primary sources verify as of this morning, separates factual disclosures from community speculation, and lays out the inventory and remediation steps your infrastructure team should run before and after the upstream patch lands.

Status as of 21 October 2026, morning UTC (and what will change today)

Right now, the industry is in a pre-release window. Upstream PHP maintainers pre-announced a coordinated release for 14:00 UTC on 21 October 2026. Security advisories from national CSIRTs and private research teams started circulating late yesterday, and the chatter about remote code execution has been loud ever since.

This article is intentionally dated. The details below reflect public knowledge on the morning of 21 October. Several key technical points will change the moment the PHP maintainers publish their official tarballs and changelogs this afternoon. When that announcement hits, don't rely on early morning analysis. Re-check the official release announcement, confirm the exact patched release numbers (the currently supported branches are 8.2, 8.3, 8.4 and 8.5), and verify whether the underlying mechanism matches what early research suggested.

Treat all third-party advice written before 14:00 UTC as provisional. Your goal this morning is not to guess how the exploit works in memory. It's to get your deployment pipeline ready so that when upstream releases clean binaries, your team can build, test, and ship them without administrative delay.

What is confirmed: the PHP notice, CVSS v4.0 9.2 x2, CVE IDs via CERT-EU, watchTowr reproduction

Separating verified facts from chatroom speculation matters during an active disclosure. As of this morning, three items are backed by primary or named sources.

First, the PHP security team published an advance notice of the security release confirming two critical vulnerabilities, with the release scheduled for 14:00 UTC today. Second, CERT-EU Security Advisory 2026-018 lists the two flaws as CVE-2026-109618 and CVE-2026-109619. Both vulnerabilities are reported as CVSS v4.0 9.2 and potentially unauthenticated remote code execution flaws.

Third, security firm watchTowr confirmed the vulnerabilities are real and said it reproduced CVE-2026-109618. It is withholding technical details until patches ship.

Everything outside these three facts is unconfirmed signal. A score of 9.2 demands immediate priority, but it doesn't mean your specific web tier is exploitable without context.

What is not confirmed: affected versions, root cause, exploitation, and the leaked-details timeline

Security researchers race to understand every zero-day disclosure, and unverified claims have multiplied across forums. Keep them separate from confirmed data.

First, the core PHP team hasn't confirmed the exact range of affected versions. Public reports, including CERT-EU citing social media and Sansec, suggest every release from PHP 5 onward may be affected. Researchers expect fixes only for supported branches, so end-of-life versions (5.x, 7.x, 8.0 and 8.1) may never get a patch. Don't assume an older PHP 7.4 runtime is safe.

Second, the root cause isn't officially documented. One unconfirmed report describes CVE-2026-109618 as a use-after-free, and others link the flaws to session upload progress handling. Neither has been confirmed by the PHP team. Third, exploitation status is contested: Huntress and watchTowr reported no in-the-wild exploitation, while Aikido's advisory was updated to say Cloudflare reports exploitation has started. Treat exposure as likely, and expect activity to grow once the fix can be diffed.

Finally, the leaked timeline remains murky. Details first surfaced on 20 October in a Hacker News post that was later deleted, ahead of a coordinated disclosure originally set for 22 October, and PHP moved its release forward a day. A proof of concept has circulated online, but nobody has confirmed it works. Ignore the rumours and watch the official php.net announcement and the PHP security advisories on GitHub at release time.

Prepare before 14:00 UTC: inventory PHP in hosts, containers, base images, CI, vendors and managed platforms

Don't wait for 14:00 UTC to find out where PHP runs in your organization. A patch is useless if you don't know which workloads need it. Spend the morning on a structured audit across your entire attack surface.

Start with bare metal and virtual machines. Run shell queries across your fleet to find php-fpm, mod_php, or standalone CLI processes. Next, inspect your container registries and check your Dockerfiles and base image references. Teams often update their primary application containers and forget the utility containers, worker nodes, cron runners, and internal admin tooling built on public PHP images.

Then audit CI/CD runners. Many build pipelines use containerized PHP runtimes to run unit tests, linters, and integration checks. If those runners accept untrusted webhook inputs or parse external pull requests, they're viable attack targets. Then look outward: forgotten staging hosts, old marketing sites and orphaned subdomains are often the PHP installs nobody remembers to patch. Our guide to mapping your external attack surface covers how to find them.

Finally, inventory third-party SaaS and managed platforms. If you run WordPress, Craft CMS, Laravel Forge environments, or managed cloud instances like AWS Elastic Beanstalk, check their status dashboards. Open support tickets now to ask when their managed runtimes will get the upstream security update.

Interim measures and their limits: the reported session.upload_progress stopgap, isolating internet-facing apps, WAF caveats

Several security threads are telling administrators to disable session.upload_progress in php.ini as an immediate stopgap. Know what this does and what it doesn't.

Settings such as session.upload_progress.enabled and memory_limit were suggested early on, but Aikido reports the PHP team has since said configuration changes cannot mitigate these flaws.

This is not an official vendor mitigation. Leaning on an unverified php.ini tweak to protect your network against PHP2Shell CVE-2026-109618 creates false security. If the underlying bug sits elsewhere in the request parser, your servers stay exposed.

Web Application Firewalls (WAFs) are a similar trap. No complete WAF rule had been published as of this morning, and signature-based rules are often bypassed soon after an exploit becomes public. A community Apache stopgap that blocks multipart POST requests before they reach PHP exists, but it can break file uploads. If you have high-risk, internet-facing PHP applications that can't be patched right at 14:00 UTC, the only dependable interim mitigation is network isolation. Restrict ingress through private VPNs, IP allowlists, or Cloudflare Access until the official binaries are compiled and deployed.

Patch-day checklist: read the official versions, upgrade, rebuild images, verify, and hunt for signs of exploitation

When 14:00 UTC arrives and upstream publishes the security advisories, work through this checklist in order:

1. Verify the release notes: Open the official php.net news page and the PHP 8 changelog. Note every patched version number and read the descriptions for CVE-2026-109618 and CVE-2026-109619. Confirm whether specific php.ini directives or compilation flags are named.

2. Pull official upstream packages: Skip unofficial third-party repositories and quick-fix deb packages from unverified sources. Wait for your upstream Linux distribution or the official Docker library maintainers to publish signed builds.

3. Rebuild and invalidate base image caches: Run clean container builds with the --no-cache flag so that RUN apt-get update && apt-get upgrade directives pull the newly patched binaries instead of reusing cached layers.

4. Verify deployment runtime versions: A green deployment pipeline doesn't prove the rollout worked. Run validation commands (such as php -v or php-fpm -v) directly against running pods or virtual machines to confirm the active process is running the patched version.

5. Hunt for post-disclosure exploitation signs: Review your web server logs for anomalies before the patch. Look for spikes in multipart/form-data POST requests to scripts that don't handle file uploads, unusual child process crashes (SIGSEGV or core dumps) in php-fpm logs, and sudden outbound network connections spawned by web server users like www-data. Following Huntress and Florian Roth's process-watcher, watch for PHP or web server processes (php-fpm, php-cgi, httpd, apache2) spawning shells or download tools such as sh, bash, curl, wget or nc, and check web roots for new or altered files, web shells, new cron jobs and new accounts. A high-severity zero-day needs verification, not assumptions.

End-of-life PHP: the hardest case

If the fixes ship only for supported branches, anything on PHP 5.x, 7.x, 8.0 or 8.1 may stay vulnerable indefinitely. Distributions and some hosting providers backport security fixes to older packages, so check your vendor's advisory before assuming there is no fix. Where none arrives, the realistic options are upgrading to a supported branch, putting the service behind a VPN or IP allowlist, or taking it offline. An internet-facing EOL PHP service with no backport is worth treating as an incident in its own right, not a backlog item.

Conclusion

Patching PHP2Shell CVE-2026-109618 is your immediate priority today. Track the official PHP release at 14:00 UTC, pull verified distribution updates, rebuild your containers, and confirm runtime process versions across every public asset.

Afterwards, keep watching the official advisory and your distribution's security tracker: affected versions, root cause details and detection guidance are likely to be refined over the coming days.

Official sources and references

• PHP security team, Upcoming Critical PHP Security Release (20 October 2026)
• PHP supported versions and the PHP 8 changelog
• PHP security advisories on GitHub
• CERT-EU Security Advisory 2026-018
• watchTowr, CVE-2026-109618 FAQ
• Huntress, Rapid Response: php2shell