Last updated: 22/10/2026

If your website, app backend or admin panel runs on PHP, update PHP today. On 21 October 2026 the PHP project released security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together called "php2shell". Both can let an attacker who is not logged in run their own code on your server. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This article explains what the flaws are, who is affected, what Singapore's Cyber Security Agency has advised, and the exact steps to take if you cannot patch straight away. Every fact below was checked against its source on 22 October 2026.

Code editor showing PHP source code with a project file list on the left
The flaws sit in the PHP runtime itself, below the application code, so they can be reached before your own code runs. Photo: Pixabay / Pexels.

What happened

The PHP project announced two critical flaws in the PHP runtime on 20 October 2026 and shipped fixed releases the next day. The advance notice on php.net said the release was "scheduled for Wednesday, 21 October 2026 at 14:00 UTC" and that it "addresses two critical vulnerabilities, both rated CVSS v4.0 9.2". The full advisories are published on GitHub as GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.

According to Google Cloud, "PHP and Wiz Research disclosed today two critical vulnerabilities in the core PHP language runtime that can expose applications to unauthenticated remote code execution and memory disclosure". "Unauthenticated" is the important word: an attacker does not need an account on your site.

The two flaws, in plain terms

Both flaws let attacker-controlled data reach memory that PHP believes is valid, which can be turned into running the attacker's code. The PHP project describes them this way:

  • CVE-2026-109618, "RCE via OOM corruption": "out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid."
  • CVE-2026-109619, "RCE via stale global state": "request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it."

The second flaw can also leak memory. The GHSA-6wmf advisory lists the confirmed impact as "unauthenticated heap use-after-free, memory disclosure and remote code execution with the web worker's privileges". The bug is old: Sansec notes that "the vulnerable code dates to PHP 5.4.0, released in 2012" and that "default configurations are vulnerable".

Table 1. The two php2shell vulnerabilities (php.net, GitHub advisories and Red Hat, checked 22/10/2026)
ItemCVE-2026-109618CVE-2026-109619
PHP's name for itRCE via OOM corruptionRCE via stale global state
AdvisoryGHSA-w8hw-w9fx-j79wGHSA-6wmf-4rv5-p3rp
Severity (PHP)CVSS v4.0 9.2CVSS v4.0 9.2
Severity (Red Hat)Important, CVSS v3 8.1See Red Hat bulletin RHSB-2026-013
Attacker needs a login?NoNo
ImpactRemote code executionRemote code execution and memory disclosure
Fixed inPHP 8.5.12, 8.4.27, 8.3.36, 8.2.35

Who is affected

Any server where PHP answers web requests is at risk, whatever the hosting set-up. The PHP advisory lists "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed", and adds: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

That last point matters for businesses that think "we keep WordPress plugins updated, so we are fine". Application updates do not help here, because the flaw is in PHP itself. Tenable notes that, according to W3Techs, "PHP is used by 69.3% of websites whose server-side language is known", and that "platforms such as WordPress, Drupal, Joomla, Laravel and Magento all run on PHP". Many mobile apps also talk to a PHP backend or admin panel built on one of these frameworks, so an app can be exposed even if nobody on the team thinks of it as "a PHP project".

The exposed footprint is large. Unit 42 says Palo Alto Networks Cortex Xpanse "has identified the presence of over 22.6 million exposed instances potentially vulnerable". VirusTotal "fingerprints roughly 5.1 million IP addresses running PHP", and among servers that disclose a version, "~272K run a supported branch (8.2 to 8.5)" while "~758K run an end-of-life branch between 5.4 and 8.1".

Why a login screen or app update does not protect you

The attack happens before your application code runs, so nothing your application does can stop it. Datadog Security Labs reproduced both flaws independently and "confirmed that application-level authentication can't block an attack: PHP processes the malicious request before any application code runs. Only patching fixes these vulnerabilities." Tenable reports that Calif, the research team credited with the exploit, "confirmed pre-authentication remote code execution against specific versions of popular PHP applications, including WordPress, Drupal, Joomla and Magento".

Exploitation is not equally easy everywhere, and it is worth reading the vendor detail for your own stack. For CVE-2026-109618, Red Hat notes that "reliable exploitation requires precise heap manipulation and timing", and that "standard Red Hat Enterprise Linux deployments use PHP-FPM rather than mod_php", which makes remote code execution "difficult in practice" for that set-up. Difficult is not the same as impossible, and the PHP project's own advice is unchanged: update.

Data centre aisle with black mesh-door server racks, blue network cables and a monitor on a cart at the end of the row
Every PHP server handling web requests is in scope, from shared hosting to dedicated clusters. Photo: Brett Sayles / Pexels.

Is it being exploited?

Reports differ by source and by time, so treat any internet-facing PHP server as a target. On 21 October, CISA wrote that it "has not observed exploitation of these vulnerabilities as of the time of publication". The same day, Datadog Security Labs wrote: "As of October 21, we have multiple reports of active exploitation in the wild. We're also aware of broad untargeted scanning going on." Sansec reported that "Cloudflare reported early attacks at 07:43 UTC on October 21, before the 14:00 UTC release" and that it expects "mass exploitation now that the patch and the writeups are public". Rapid7 adds that "exploitation in-the-wild is expected". On the other side, Huntress wrote that "as of October 21 at 4:30pm ET, Huntress has not observed in-the-wild exploitation on partner systems".

What Singapore's CSA advises

Singapore's Cyber Security Agency published alert AL-2026-151 on 21 October 2026, with the headline advice: "Patch immediately." The alert states that "these vulnerabilities affect all versions of PHP" and that "users and administrators of affected products are advised to update to the latest versions immediately".

CSA's recommendations go further than "update PHP". Organisations are advised "to identify systems running any version of PHP and apply the security updates, prioritising internet-facing systems", and to "check whether PHP is installed on their web servers, including where it may be used by third-party applications or components, even if their primary websites do not use PHP". That is the step most often missed: an old monitoring tool, a forgotten marketing microsite or a vendor's admin panel can carry PHP even when your main product does not.

If a server that held personal data was compromised, Singapore's breach-notification rules may also apply. We covered how the PDPA's notification duty works in our app store submission checklist, which cites the relevant sections of the Act.

How to fix it

The only complete fix is to update PHP. The PHP project says: "Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35", and that "Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages". After updating, restart every PHP worker so that no process is still running the old code.

Older versions are a harder problem. The PHP project states that "PHP 8.1 and older no longer receive updates from the PHP project". It did provide "minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor", but there are no official releases for those branches. CISA's advice for those systems is blunt: organisations that "continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated". PHP 8.2 is also near its end: the release notes say it "reaches end of life on 31 December 2026 and will receive no further security fixes after that date".

The patch changes how PHP behaves when memory runs out. Datadog explains that "a soft limit now defers the error until PHP reaches a safe point, which lets an in-progress operation finish initializing its data", and that above a higher hard limit "PHP terminates the worker at once" rather than cleaning up potentially invalid state. The patch "also resets request-owned global state before anything can reuse it", which closes the stale-state path behind CVE-2026-109619. This is why a restart matters: workers started before the update keep running the old code.

Table 2. What to do by PHP version (php.net and CISA, checked 22/10/2026)
Your PHP versionStatusAction
8.5.xFixed in 8.5.12Update now and restart workers
8.4.xFixed in 8.4.27Update now and restart workers
8.3.xFixed in 8.3.36Update now and restart workers
8.2.xFixed in 8.2.35; end of life 31 December 2026Update now, and plan an upgrade to 8.3 or later before year end
7.4, 8.0, 8.1No releases; minimal source-backports onlyUse a vendor backport or build from source; CISA advises taking systems offline until patched
Older than 7.4No updates and no backports from the PHP projectUpgrade to a supported version; CISA advises taking systems offline until patched

If you cannot patch today

Temporary settings changes reduce exposure but are not a fix. The PHP project is explicit that they "reduce exposure to specific attack paths but do not make an installation safe". With that warning, the official guidance is:

  • For CVE-2026-109619: "Set session.upload_progress.enabled=0 and restart every worker", using php.ini, an FPM pool or server configuration. "Do not rely on ini_set() or FPM .user.ini." On PHP 8.5, also "set fatal_error_backtraces=0 and restart every worker".
  • For CVE-2026-109618: "Set memory_limit=-1, preferably in a way applications can't override, such as php_admin_value in the FPM pool or Apache configuration".
  • Limit request size: "For applications that don't require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M."
  • Block file-upload style requests if you do not need them: Rapid7 advises: "If the application does not use multipart data, block those requests before they reach PHP." Sansec explains why: "Every known trigger is a multipart/form-data request, the format browsers use for file uploads."

Removing the memory limit has a cost. Sansec warns that "with memory_limit = -1, a single request can use all server memory", and advises watching memory use and restoring the limit once PHP is updated. CISA adds that "a web application firewall may provide some protection until systems are updated or patched", and Google Cloud has published Cloud Armor guidance for its customers. Tenable reports that "Cloudflare has deployed WAF rules for the known exploit vectors, available to all customers including the free tier", but notes that Cloudflare "describes this as a stopgap only" and that "the rules only cover traffic routed through Cloudflare".

Screen in a dark room showing multiple terminal panes with system logs, error codes and CPU and memory stats
After patching, review PHP and web server logs for memory exhaustion errors and unexpected processes. Photo: Tima Miroshnichenko / Pexels.

A checklist for this week

Work through these in order; the first three matter most.

  1. Find every PHP server. Include vendor tools, microsites and admin panels, as CSA advises. Check internet-facing systems first.
  2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from your Linux distribution or hosting provider, then restart all PHP workers.
  3. Isolate anything on PHP 8.1 or older until it is upgraded or covered by a vendor backport.
  4. If patching is delayed, apply the temporary settings above at server level, and watch memory use.
  5. Check for signs of compromise. Datadog advises looking "for large form submissions, memory-exhaustion errors during request initialization, and unexpected shell processes". It also notes that "successful command execution doesn't necessarily crash the worker", so a server that looks healthy is not proof that it was not attacked.
  6. Plan the PHP 8.2 upgrade before its end of life on 31 December 2026.

How Namtech can help

Many of the apps we build and maintain talk to a backend API or admin panel, and some of those run on PHP. If you are not sure which PHP versions sit behind your app or website, or you need help planning an upgrade from an end-of-life version, send us a short brief. We can audit the servers, plan the update and handle the release. Ongoing work of this kind is what our maintenance and support plans cover.

php2shell (CVE-2026-109618 and CVE-2026-109619) lets an unauthenticated attacker run code on any PHP server that handles web requests; the only complete fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, and Singapore's CSA advises finding every system running PHP and patching internet-facing ones first.

This article summarises public advisories for general information and is not security or legal advice. Reports on exploitation were changing quickly when we published; check the sources for updates.

Sources