PHP2Shell: Critical PHP Flaws Leaked Early, Patches Out Now

Two critical PHP remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, leaked before their planned disclosure. PHP released fixes on 21 October 2026. What Hong Kong businesses running PHP sites should check and do now.

Two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619 (nicknamed "PHP2Shell"), can let an unauthenticated attacker run code on a web server. Details leaked before the planned disclosure, and the PHP project released fixed versions on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your website, online shop or internal system runs on PHP, including WordPress, check which version it uses and update, or ask your hosting provider when they will.

What happened

The two flaws were under embargo, a period when researchers and vendors keep details private so patches can be prepared. On 20 October 2026, a since-deleted Hacker News post claimed two critical PHP remote code execution bugs would be disclosed on 22 October, BleepingComputer reported. Security firm watchTowr then said on X that information had leaked and that the vulnerabilities were real.

The same day, the PHP security team gave advance notice of a security release for 21 October at 14:00 UTC (22:00 Hong Kong time), saying both issues were rated CVSS v4.0 9.2. Hong Kong's GovCERT.HK issued a High Threat Security Alert (A26-10-36) on 21 October. The official advisory and fixed releases followed that evening.

What the two vulnerabilities are

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): when PHP runs out of memory while handling a request, internal request data can be left partly initialised. The clean-up step may then treat that invalid data as valid.
CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): state belonging to one request can survive after its memory is freed. A later request handled by the same worker may use it before normal initialisation resets it.

Both are rated Critical, CVSS v4.0 9.2, in the CVE records published by PHP. The score reflects network access, no login and no user interaction, with high attack complexity. Reports before the release described them as CVSS 10.0; the official score is 9.2.

Who is affected

According to the PHP advisory, all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.

PHP 8.2 to 8.5: versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. Update to those releases.
PHP 8.1 and older: the PHP project no longer ships updates. Some Linux distributions and long-term support vendors provide backported fixes, and PHP published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source. Otherwise, move to a supported version.
PHP 8.2 reaches end of life on 31 December 2026, so plan the next upgrade as well.

Is it being exploited?

Cloudflare reported that it saw attack traffic targeting its customers after the leak, and that WAF rules have protected its free and paid WAF plans by default since 21 October, 03:02 UTC. Cloudflare still tells customers to patch. The picture may change quickly, so treat any internet-facing PHP system as urgent.

What to do now

List your PHP systems. Include company websites, WordPress or other CMS sites, online shops, booking or membership systems, admin portals and any internal tool reachable from the internet. Put internet-facing systems first.
Check the PHP version. Your hosting control panel usually shows it, or a developer can check on the server. Note how PHP runs (mod_php, PHP-FPM, LiteSpeed and so on).
Update. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution's patched package. Ubuntu, for example, has published fixed packages for its supported releases. Restart PHP workers afterwards so the new version is actually running.
Ask your hosting provider. On shared or managed hosting, the provider usually controls PHP. Ask whether they have patched, and when.
If you use the Remi repository: PHP notes that the volunteer-run rpms.remirepo.net would not have updates on release day and suggests distribution packages or building from source.
Use a WAF as a stopgap, not a fix. A web application firewall or CDN with managed rules may block known attack patterns. PHP says updating is the only complete solution.
Test, then watch. If you can, try the update in a staging environment first, then monitor the live site. External website monitoring helps you spot downtime or unexpected changes.

If you cannot update today

PHP's advisory lists temporary measures that reduce exposure to specific attack paths but do not make an installation safe. They need server-level access and should be applied by whoever manages the server:

For CVE-2026-109618: set memory_limit=-1 at a level applications cannot override, keep post_max_size low (PHP suggests 8M without uploads, 32M with uploads), and limit request size and complexity at the web server or proxy.
For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0.

The full PHP advisory has more detail, including settings to avoid. The UK's NCSC has advised organisations to consider taking a system offline when it cannot be fixed straight away.

What this means for SMEs

Many small businesses do not know which PHP version their website runs, or who is responsible for updating it. This is a good moment to find out and write it down: who hosts the site, who can update the server, and how fast they respond. A clear support SLA makes that explicit before the next urgent patch. technine.io can help check exposure and plan fixes through cybersecurity and compliance work, and keep systems updated through managed support.

Frequently asked questions

Is my WordPress site affected?

WordPress runs on PHP, so it depends on the PHP version on your server, not the WordPress version. If PHP is older than the fixed releases, the site is exposed until PHP is updated.

Will a WAF or CDN protect me?

It may block known attack patterns and buy time. It is not a complete fix; you still need to update PHP.

We are on PHP 7. What should we do?

PHP 7 no longer receives official updates. Check whether your Linux distribution or support vendor provides a backported fix, and plan a move to a supported PHP 8 version.

How do I know the update worked?

Confirm the new version number on the server or in your hosting panel, make sure PHP workers were restarted, and check that key pages and forms still work.