PHP2Shell, Next.js RCE and UpdraftCentral: Uncloaked Digest

Uncloaked: PHP2Shell Leaked a Day Early, and It Wasn't the Only Remote Code Execution Bug This Week

Most weeks, the vulnerabilities that matter are in a plugin, a library or an appliance. This week one of them was in PHP itself, the language behind most of the websites whose server-side language is known. It leaked before the fix was ready, and attackers started probing for it before the patch shipped.

It wasn't alone. Two remote code execution bugs landed in Next.js, a WordPress management service lost the keys to its customers' sites, and CISA added another batch of exploited edge devices to its catalogue. Remote code execution (RCE) means an attacker can make your server run commands of their choosing, and it appears in three of the four stories below.

1. PHP2Shell: critical PHP flaws, leaked before the patch

What happened

On 20 October, a post on Hacker News named two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, ahead of their planned disclosure. The post was deleted, but screenshots spread. The pair became known as "PHP2Shell", after the name of an exploit chain shown in a short demo video.

The PHP security team confirmed the flaws, rated both critical (CVSS v4.0 score 9.2, not the 10.0 first claimed), and brought the release forward to 21 October. CERT-EU and the UK's NCSC both issued advisories telling organisations to prepare to patch immediately. The fixes shipped this afternoon.

What the flaws are

Both are memory corruption bugs in the PHP engine, not in any particular application:

CVE-2026-109618 is in out-of-memory handling. If PHP runs out of memory part-way through setting up a request, the clean-up code can treat half-initialised data as valid.
CVE-2026-109619 is stale state. Internal data can outlive the memory behind it, so a later request handled by the same PHP worker can use it before it is reset. Reporting describes a demonstrated exploit that needs no authentication and triggers from a single request, before any application code runs. That last part matters: it doesn't matter how well your WordPress, Laravel or Drupal code is written. Any PHP install serving web requests is in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php setups are described as the highest risk.

Exploitation

Before the patch was out, Patchstack reported exploitation attempts against several hosting partners, and Cloudflare said it was seeing early attacks. Proof-of-concept repositories also appeared on GitHub. Tenable said it could not verify that any of the circulating code worked, and some of it may be malicious, so don't run unverified exploit code to "test" your own server.

Fixed versions

PHP branch	Fixed in
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
7.4, 8.0, 8.1 (end of life)	Minimal source patches only, no official release
Older than 7.4	No fix

Linux distributions received patches ahead of the public release, so check your distribution or hosting provider for backported packages.

What not to rely on

php.ini tweaks. An early suggestion that disabling session.upload_progress would help was withdrawn by the researchers who made it. PHP's own developers have said the only fix is to upgrade.
A WAF on its own. Cloudflare shipped emergency rules for known exploit patterns, including for free customers. It calls them an extra layer, not a fix, and they only cover traffic that passes through Cloudflare. If you can't patch a public-facing PHP server today, the NCSC's advice is to take it offline until you can.

Why it matters

Updating WordPress, or your framework, does not update PHP. On shared or managed hosting, your provider patches the runtime. On a VPS, a container image or an appliance with PHP bundled inside, that is your job, and it is easy to forget the copy of PHP inside a control panel or a vendor product.

Where Decloak fits, and where it doesn't

Our server software check reads version strings that a server discloses, such as an X-Powered-By: PHP/8.3.x header, and checks them against the NVD (the US National Vulnerability Database). If your server announces an unpatched PHP version, the report will show it, and the disclosure itself is flagged as a finding.

The honest limits:

Many servers hide the PHP version. If yours does, we can't tell whether it is patched, and a missing version is not evidence that it is.
Database entries lag. Brand-new CVEs can take time to appear in the NVD with the version data matching relies on.
We don't attempt the exploit. We won't fire PHP2Shell at your server to see if it works. The reliable check is on the server itself: run php -v (and check every PHP binary, not just the one on your PATH), then patch.

2. Next.js: two unauthenticated remote code execution bugs

Vercel published a security update for Next.js on 14 October, and Singapore's Cyber Security Agency followed with a "patch immediately" alert. Both bugs score 9.5 on CVSS v4.0 and let an unauthenticated attacker run code on the server:

GHSA-673q-mjm6-r5xr affects apps using the App Router with Cache Components, triggered when a "use cache" function returns multiple typed arrays.
CVE-2026-96889 affects Next.js on glibc-based Linux, through a memory bug in an upstream library used for image optimisation. The fixes are in 16.4.1 for the 16.x line and 15.5.28 for versions 10 to 15.

Next.js is the default for a large share of apps built with AI coding tools, and many of those are deployed once and left alone. If you or your AI agent created a Next.js project in the last two years, check the version in package.json and redeploy. A self-hosted app needs you to do this. A managed platform may protect its own image optimiser, but your framework version is still your responsibility.

3. Stolen UpdraftCentral keys used to backdoor WordPress sites

TeamUpdraft, the company behind the UpdraftPlus backup plugin, said attackers accessed its website and likely its customer database. The data included connection keys for UpdraftCentral, its service for managing many WordPress sites from one place.

Those keys let the attackers send commands straight to connected sites. From 18 October, Patchstack saw them installing malicious plugins and creating administrator accounts, and it identified at least 99 malicious plugin variants, some disguised as maintenance or optimisation tools and some built to hide from WordPress's standard admin screens.

Only sites connected to UpdraftCentral with an active key are exposed, not every UpdraftPlus install. If yours was connected:

Update to UpdraftPlus 1.26.13 (free) or 2.26.13 (Premium), which revoke older cloud connections.
Delete any remaining UpdraftCentral keys.
Review administrator accounts and installed plugins, and check logs.
Change passwords and reset two-factor authentication.
If anything looks wrong, restore from a backup taken before 17 October. Revoking the key doesn't remove a plugin or account that has already been added. This is a supply-chain attack in the plainest sense: nobody broke into the sites, they used a trusted management tool's own access. An outside scan won't see a backdoor plugin hidden in your admin area, so this one needs checking from the inside.

4. The edge keeps getting exploited

CISA added nine entries to its Known Exploited Vulnerabilities (KEV) catalogue between 13 and 16 October. The catalogue lists flaws with evidence of real attacks. Most were in products that sit at the edge of a network and face the internet by design:

Product	Weakness
Ivanti Connect Secure	Authentication bypass
BeyondTrust Remote Support	Authentication bypass
Palo Alto Networks PAN-OS	Code injection
Fortinet (multiple products)	Path traversal
Cisco Secure Email Gateway	Path traversal
Atlassian (multiple products)	Files exposed to external parties
Ahsay AhsayCBS	Command injection, improper authentication

The pattern hasn't changed in years. VPNs, remote support tools and gateways are reachable from anywhere, often run with high privileges, and are patched less often than the servers behind them.

For bare IP targets, Decloak runs passive, connect-only checks on common ports and records any service banners. That tells you what is reachable, which is the first question. It doesn't confirm whether a specific appliance is vulnerable, which needs the vendor's advisory and your own version check.

The common thread

Three of these four stories are about something underneath the application. The language runtime, the framework, a management tool with keys to every site, and the gateway in front of it all. Code review and application testing don't touch any of them. Keeping an accurate inventory of what is actually running, and how it is reachable, is still the most underrated security control there is.