PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Security Report and Response Plan

Short answer: PHP2Shell is the name for two critical flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, fixed in an emergency release on 21 October 2026. An unauthenticated attacker who can reach a PHP web server may be able to run code on it. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart every PHP worker, and find the PHP you did not know you had.

What happened, in one paragraph

On 21 October 2026 the PHP project shipped four security releases at once (8.5.12, 8.4.27, 8.3.36 and 8.2.35) to close two remote code execution flaws in the interpreter's core request handling. The flaws became known as PHP2Shell. The PHP project scores both at 9.2 (Critical) under CVSS v4.0. Its advisory says the risk applies to "all PHP installations serving web requests", whether PHP runs under PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. Details leaked a day before the planned disclosure, so the patch window was much shorter than usual. Within hours, several security firms reported exploitation attempts. By 22–23 October, the US CISA, the UK NCSC, Singapore's Cyber Security Agency (CSA) and Hong Kong's HKCERT had all issued alerts.

This report sets out what is known, what is still uncertain, and what an IT or security lead in Hong Kong, mainland China or Singapore should do in the next 24 hours, 72 hours and 7 days. It is written for the people who must decide and act, not only for engineers.

What exactly are CVE-2026-109618 and CVE-2026-109619?

Both flaws sit inside PHP itself, below the level of WordPress, Drupal, Laravel, Magento or any plugin. Keeping your application up to date does not protect you. Only an updated PHP runtime does.

CVE-2026-109618: remote code execution via out-of-memory corruption

PHP's advisory (GitHub advisory GHSA-w8hw-w9fx-j79w) describes it this way: out-of-memory handling can interrupt PHP while internal request data is only partly set up. The request clean-up code may then treat that half-built data as valid. An attacker who can push a PHP worker into an out-of-memory condition at the right moment can turn that confusion into control of the process. Google's response guidance notes that large request payloads may be used to trigger the out-of-memory condition.

CVE-2026-109619: remote code execution via stale global state

The second advisory (GHSA-6wmf-4rv5-p3rp) describes request-owned internal state that survives after its memory has been freed. A later request handled by the same PHP worker may use that stale state before normal start-up resets it. Singapore's CSA classes this as a use-after-free flaw. Because PHP workers are long-lived and serve many requests, one visitor's request can affect the next one on the same worker.

Who is most at risk?

The PHP project states that it considers the risk highest for Apache with mod_php. There it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. That detail matters. A login page, an application firewall built into your code, or a hardened CMS configuration does not help, because the attack lands before any of it executes. The University of Toronto's advisory adds that the PHP-FPM path for CVE-2026-109619 needs a suitable application operation. That makes it harder, but not safe.

How severe is it, really?

• PHP project: 9.2 Critical under CVSS v4.0 for both flaws.
• Some public vulnerability databases: CVSS v3.x scores of 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619.
• watchTowr: treats the issue as a 10.0, given how widely PHP is deployed and how little the attacker needs.

The scores differ, but the conclusion does not. Unauthenticated remote code execution on internet-facing web servers is a drop-everything event.

Timeline: from discovery to active exploitation

Public reporting is still being corrected, so the timeline below uses only dates confirmed by at least one primary or well-sourced report. All times are UTC.

• August 2026: Researchers independently find the flaws. Public reporting credits teams at Calif and at Wiz, both using AI-assisted analysis. One of the underlying out-of-memory problems had reportedly been noticed in a 2024 audit but was never fixed.
• 17 October 2026: Amazon Threat Intelligence later reported an exploitation attempt in its honeypot telemetry from this date, four days before public disclosure.
• 20 October 2026: Details leak on Hacker News ahead of the planned 22 October disclosure. The PHP project announces an emergency release for 21 October at 14:00 UTC.
• 21 October 2026, 13:34 UTC: The two GitHub security advisories go public, shortly before the scheduled release.
• 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released, with minimal source backports for 8.1, 8.0 and 7.4. Singapore's CSA and the US CISA issue alerts. watchTowr reports exploitation attempts against its honeypot network, and Cloudflare reports early attempts and deploys temporary WAF rules.
• 22 October 2026: HKCERT publishes a warning urging Hong Kong businesses to review and patch PHP systems. CSA updates its alert. Google Cloud updates its WAF and detection guidance. As of this date, neither CVE had been added to CISA's Known Exploited Vulnerabilities catalogue.
• 23 October 2026: HKCERT updates its security bulletin, first released on 22 October, which rates the issue Extremely High Risk and states that the flaws are being exploited in the wild.

The lesson is plain. The gap between disclosure and attack is now measured in hours, not weeks. HKCERT makes the same point: AI tools are shortening the time between disclosure, scanning and attempted exploitation.

Which PHP versions are affected, and which are fixed?

Every maintained branch is affected until it is updated, and so is almost every older one.

• PHP 8.5: affected before 8.5.12. Fixed in 8.5.12.
• PHP 8.4: affected before 8.4.27. Fixed in 8.4.27.
• PHP 8.3: affected before 8.3.36. Fixed in 8.3.36.
• PHP 8.2: affected before 8.2.35. Fixed in 8.2.35. Note that PHP 8.2 reaches end of life on 31 December 2026.
• PHP 8.1, 8.0 and 7.4: affected, end of life. No official binary release. The PHP project published minimal source backports, and some Linux distributions and long-term support vendors ship patched packages.
• PHP 7.3 and older, including PHP 5.x: affected, with no fix. The only safe path is to upgrade to a supported branch, or to take the system off the internet.

Two practical traps catch teams out:

• Vendor backports keep the old version number. On a patched distribution or control-panel build, `php -v` may still show the old version. Confirm the fix by checking that the vendor's changelog or advisory lists both CVE IDs.
• Not every repository updated on day one. The PHP project specifically advised users of the third-party rpms.remirepo.net repository to switch to distribution packages or build from source, because that repository would not have updates on release day.

Why this matters for businesses in Hong Kong, China and Singapore

PHP runs a very large share of the web. HKCERT cites reports that more than 75% of websites use it, and an estimate of about 5.1 million internet-connected PHP hosts. But the bigger risk for most Asian businesses is not their main website. It is the PHP they do not know about.

PHP hides in places your asset list does not cover

HKCERT warns that PHP may be built into the administration interfaces and operational parts of applications, networking and security appliances, storage systems and monitoring systems. Those embedded copies often run a different PHP version from the operating system, so routine inventories miss them. Typical places to look include:

• Web hosting control panels such as cPanel, Plesk, HestiaCP and VestaCP, which ship their own PHP builds.
• Legacy intranets and HR, booking or ticketing tools built years ago by a local agency and never upgraded past PHP 7.
• Network, firewall, VPN, NAS and monitoring appliances with a PHP-based web console.
• Marketing sites and e-commerce stores on WordPress, WooCommerce, Magento or OpenCart, often hosted by a third party.
• Containers and images that bundle PHP and are rebuilt rarely.

Regulators and insurers will ask about it

For regulated firms, this is also an evidence question. Singapore's CSA has advised organisations to audit every system running PHP, prioritise internet-facing servers, and check for indirectly bundled components. Hong Kong firms under HKMA or SFC supervision, and mainland operations under MLPS (等保) obligations, should expect auditors, customers and cyber insurers to ask a simple question: when did you know, what did you patch, and how can you prove it? A dated patch record, a scan result and preserved logs answer that question. "We think we are fine" does not.

What should you do now? A 24-hour, 72-hour and 7-day plan

The steps below follow the PHP project's advisory and the guidance from HKCERT, CSA and CISA. Treat them as a sequence, not a menu.

Within 24 hours: find, patch, restart

• Inventory every PHP runtime you own or host. Start with internet-facing servers. Include control panels, appliances, containers and third-party hosted sites. Ask each hosting provider and software vendor in writing for their patch status.
• Update to a fixed release. Install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or the patched package from your distribution or control panel vendor. Ubuntu and SUSE, among others, have released updates.
• Restart every PHP worker. The fix is not active until old workers are gone. Restart PHP-FPM pools, Apache with mod_php, and any long-running PHP process. Rebuild and redeploy containers; a patched base image does nothing for a container that is still running.
• Patch mod_php first. Apache with mod_php carries the highest risk, so those servers go to the front of the queue.
• Verify the fix by CVE ID, not by version string, wherever a vendor backport is in use.

If you cannot patch today: reduce exposure

The PHP project is explicit that no configuration change fully mitigates these flaws. Temporary measures only narrow specific attack paths. If a system cannot be updated within hours, apply as many of these as you can and plan the update anyway:

• Take it off the internet or isolate it. HKCERT and watchTowr both recommend restricting or removing public access to any PHP system that cannot be patched at once. This is the only interim step that removes the risk rather than reducing it.
• For CVE-2026-109619: set `session.upload_progress.enabled=0` in `php.ini`, the FPM pool or the server configuration, then restart every worker. Do not rely on `ini_set()` or `.user.ini`. On PHP 8.5, also set `fatal_error_backtraces=0`.
• For CVE-2026-109618: cap request sizes at the web server or proxy, including body size, field count, multipart part count, header count and nesting depth. Keep `post_max_size` low (the advisory suggests 8M without uploads, 32M with uploads). Contain workers with a container or cgroup memory limit that kills only the affected worker. The advisory also describes setting `memory_limit=-1`, while warning that this alone does not make an installation safe.
• Turn on managed WAF rules where you have them. Cloudflare deployed temporary rules. Google Cloud recommends Cloud Armor managed rules and a request-body inspection limit. Treat these as a seatbelt, not a fix. CloudLinux, for example, has noted that its firewall rules could not yet cover one of the two attack paths.

Within 72 hours: look for signs you were already hit

Exploitation attempts were reported from 21 October, and Amazon reported an attempt as early as 17 October. Patching closes the door; it does not tell you whether someone came in first.

• Preserve logs before they rotate. Keep web server, PHP-FPM, WAF and firewall logs from at least mid-October onwards. CSA specifically encourages reviewing logs back to mid-October.
• Look for unusual requests and process behaviour. Watch for oversized or malformed requests, bursts of out-of-memory errors or worker crashes, and PHP or web server processes spawning shells or unexpected child processes.
• Check for persistence. Look for new or changed PHP files in web roots and upload folders, unknown cron jobs, new local accounts and unexpected outbound connections. The UK NCSC has specifically urged organisations to watch for backdoors.
• Escalate if anything looks wrong. If you find signs of compromise, isolate the host, keep the evidence and bring in incident response. Rebuilding from a known-good image is safer than cleaning a live server.

Within 7 days: close the structural gaps

• Retire PHP 8.1 and older. Backports buy time; they do not make an end-of-life branch safe for long. Plan the move off PHP 8.2 too, since it reaches end of life on 31 December 2026.
• Fix the inventory gap. If this event surfaced PHP you did not know about, your asset register is incomplete. Add embedded and vendor-managed systems to it.
• Put patching on a clock. Agree a written target for critical, internet-facing fixes, measured in hours rather than the next maintenance window, and report against it.
• Record what you did. Keep a dated log of the inventory, patch times, verification and log review. It is the evidence your board, regulator, customers and insurer will ask for.

Patch, backport, mitigate or isolate: which option fits?

Most estates will use more than one of these at once. Here is how they compare.

Four responses compared

• Official update (8.5.12, 8.4.27, 8.3.36, 8.2.35). Closes both flaws. Requires a restart, and a quick application smoke test. This is the only complete fix and the default for every supported system.
• Vendor or distribution backport. Closes both flaws on an older branch without a major upgrade. Depends on the vendor; verify by CVE ID because the version number may not change. A reasonable bridge for PHP 8.1, 8.0 or 7.4, not a destination.
• Configuration mitigations and WAF rules. Narrow specific attack paths within minutes. Incomplete by the PHP project's own statement, and can break legitimate uploads or progress bars. Use only while an update is being prepared.
• Isolation or temporary shutdown. Removes internet exposure entirely. Costs availability. The right call for PHP 7.3 and older, for unpatchable appliances, and for any system you cannot update within a day. Several European and Canadian public bodies chose this route in the first 48 hours.

The wider lesson: AI has compressed the patch window

Two things make PHP2Shell different from a routine critical bug. First, the flaws were found with AI-assisted tooling, and attackers have the same tools. Second, the leak and the early release of patched builds meant that attackers could compare old and new code within hours. HKCERT's own headline makes the point directly: AI is accelerating both attack and defence and shortening the response window.

For a mid-sized company, the practical consequence is that "we patch on the second Tuesday of the month" is no longer a security policy for internet-facing systems. What protects you is a short chain that works on any day of the week:

• Know what you run. A live inventory, including embedded and third-party-hosted software.
• See what is exposed. Regular external vulnerability scanning, so a critical finding surfaces before an attacker finds it.
• Patch on a clock. A named owner and a written time target for critical fixes, with a restart and a verification step.
• Watch for the attempt. Log retention and monitoring that would show an exploitation attempt, rather than learning about it from a ransom note.

How Brocent can help

Brocent provides managed IT support and cyber security services to businesses across Hong Kong, mainland China, Singapore and the wider Asia-Pacific region. For PHP2Shell and similar events, the relevant pieces are:

• Exposure check. An external vulnerability scan to find internet-facing PHP and other critical exposures, or a broader IT security assessment.
• Patch on a clock. Managed vulnerability scanning and patch management, with patch compliance reporting. See patch management pricing if you want this service on its own.
• Inventory and hardening. An IT assessment and audit to bring embedded systems, control panels and legacy applications into one register and plan the move off end-of-life PHP.
• Perimeter controls. Network security options, including firewall and WAF rules, as a compensating control while systems are updated.

If you are unsure whether a system in your estate is affected, contact Brocent and our team will help you work through the checklist above.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the common name for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP interpreter disclosed and fixed on 21 October 2026. They can allow an unauthenticated attacker to execute code on a server that runs PHP and serves web requests.

Does updating WordPress, Drupal or my plugins fix it?

No. The flaws are in the PHP engine itself, below the application. Only an updated PHP runtime, or a vendor package that backports the fix, closes them. Keep your CMS and plugins updated anyway, but treat that as a separate task.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1, 8.0 and 7.4, use a distribution or long-term support vendor package that lists both CVE IDs. PHP 7.3 and older have no fix and should be upgraded or isolated.

Is PHP2Shell being exploited?

Yes, according to several sources. watchTowr and Cloudflare reported exploitation attempts from 21 October 2026, Amazon reported an attempt dated 17 October, and HKCERT's bulletin, updated on 23 October, states the flaws are being exploited in the wild. As of 22 October, CISA had not added either CVE to its Known Exploited Vulnerabilities catalogue, so the picture is still developing.

Is there a workaround if I cannot patch today?

Only partial ones. The PHP project says no configuration change fully mitigates the flaws. Disabling `session.upload_progress`, tightening request size limits and enabling WAF rules reduce specific attack paths. Taking the system off the internet is the only interim step that removes the exposure.

How do I check whether a server is patched?

Run `php -v` and compare it with the fixed versions. If you use a distribution, control panel or vendor build, check its changelog or advisory for both CVE IDs, because backports often keep the old version number. Then confirm that every PHP worker has been restarted since the update.

Are network appliances and control panels affected?

They can be. HKCERT warns that PHP is often embedded in the administration interfaces of appliances, storage and monitoring systems, and control panels such as cPanel and Plesk ship their own PHP. Ask each vendor for their patch status and apply their update.

What should I tell my board, customers or insurer?

State what you found, what you patched and when, how you verified it, and whether log review found any sign of compromise. A dated record of the inventory, patch times and log review is the evidence they will expect.

Sources

This report draws on primary advisories and well-sourced reporting available on 23 October 2026. The situation is developing; check the official advisories for the latest status.

• PHP project security announcement, 21 October 2026
• HKCERT: warning on critical PHP2Shell vulnerabilities
• Cyber Security Agency of Singapore: Critical Vulnerabilities in PHP (PHP2Shell)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Google Cloud: Responding to core PHP vulnerabilities
• watchTowr: PHP2Shell FAQ