Two critical vulnerabilities in PHP have triggered an urgent security response. On 21 October 2026, the PHP development team released emergency patches for CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. Both can let an unauthenticated attacker execute code remotely on a vulnerable web server, and both carry a CVSS v4.0 score of 9.2 (Critical).

The issue is especially serious because the flaws sit in the PHP runtime itself. Even an application with secure business logic can be exposed if the PHP environment underneath it is vulnerable. Exploit techniques have been demonstrated, proof-of-concept material is circulating, and several sources have reported exploitation attempts. For any organization that relies on PHP-powered websites, CMS platforms, e-commerce stores, APIs or business applications, this needs attention today.

PHP2Shell at a glance

What is PHP2Shell?

PHP2Shell is the name given to two remote code execution (RCE) vulnerabilities in the PHP runtime. RCE means an attacker can make a system run code of their choosing, which can lead to full compromise of the server and the applications on it.

Unlike flaws that depend on a particular endpoint or coding mistake, PHP2Shell affects the engine that processes web requests. According to CERT-EU Security Advisory 2026-018, both issues arise from unsafe handling of memory and internal request state under specific error conditions.

CVE-2026-109618: memory corruption during out-of-memory handling

PHP enforces a configurable memory limit and aborts any request that exceeds it. That abort can interrupt PHP while internal request data, for example during file-upload parsing, is only partly initialized. Cleanup code may then treat the invalid data as valid and try to free memory that was never properly set up. Because that memory can still hold attacker-influenced data from earlier allocations, the corruption can potentially be turned into code execution.

Why it matters: A crafted request may be enough to reach the vulnerable path, with no login required.

CVE-2026-109619: stale global state reused across requests

Internal state that belongs to one request can survive after the memory behind it has been freed, for instance after a fatal error. If a later request handled by the same worker uses that stale state before PHP resets it, PHP may process invalid internal data, creating an exploitable condition.

Why it matters: A failure during one request can leave behind state that changes how a later request is processed.

Researchers also showed that an attacker may be able to read memory from a PHP worker process, which can hold passwords, session tokens, API keys and certificates belonging to other requests, even without achieving code execution.

How The PHP Flaws Came To Light

The flaws were found by Wiz Research, Calif and OpenAI’s Codex Security team, working with the PHP security team. The underlying code has been in PHP for more than a decade, and the flaws affect nearly every version back to PHP 5.4. Researchers say AI models helped turn these long-standing weaknesses into working exploits far faster than before.

The disclosure did not go to plan. Details leaked ahead of a scheduled 22 October disclosure, PHP announced an upcoming security release on 20 October, and the fixes shipped on 21 October. That compressed the time defenders had before technical details became public.

Which PHP Versions and Environments Are Affected

Every PHP installation that serves web requests is potentially affected, including:

• PHP-FPM: commonly used alongside web servers such as Nginx
• Apache mod_php: identified by the PHP team as the highest-risk setup, because a single unauthenticated request can trigger the attack before any application code runs
• php-cgi: the CGI implementation of PHP
• FrankenPHP: a modern application server for PHP
• LiteSpeed: web server environments that run PHP applications

The exposure goes beyond servers you manage directly:

• PHP-based applications such as WordPress, Laravel and other CMS, portal and e-commerce platforms. Updating the application does not update the PHP runtime beneath it, so check both layers separately.
• Hosting control panels, containers and images that bundle PHP.
• Third-party products with embedded PHP. Palo Alto Networks has confirmed that all versions of PAN-OS and Panorama are affected, and had not shipped fixed releases at the time of reporting. Fortinet and Cisco are still checking their product lines. CERT-EU points organisations to the NCSC-NL repository for tracking software that embeds PHP.

Fixed PHP versions

Linux distributions and long-term-support (LTS) vendors received the patches in advance. A distribution package can carry the fix under an older-looking version number, so check the package changelog for the CVE rather than relying on the version string.

What about PHP 8.1 and earlier?

These branches no longer receive fixes from the PHP project. Contact your distribution or LTS vendor about a backported patch, or migrate to a supported branch. Because of the severity, the PHP security team has also published minimal source backports for PHP 7.4, 8.0 and 8.1 for organisations that build from source or have no vendor. Note that PHP 8.2 itself reaches end of life on 31 December 2026, so plan the next upgrade now.

Is PHP2Shell Being Exploited?

The situation has moved quickly, so check for updates on the day you read this.

• Amazon Threat Intelligence recorded an exploitation attempt against its honeypot network on 17 October, four days before public disclosure. That suggests a threat actor had exploit details while the flaws were still under embargo.
• Cloudflare reported early attacks before the patch shipped and said attackers changed their payloads to get around its firewall rules.
• watchTowr reported active exploitation attempts against both CVEs on 21 October. In the sources reviewed, neither flaw had been added to CISA’s Known Exploited Vulnerabilities catalogue, and no source had confirmed a successful compromise of a specific server.

Some organisations took services offline as a precaution. BambooHR suspended its service in several regions, and a number of Dutch government and education websites went offline, although the Dutch national cyber-security centre said it had not seen the flaw abused. Researchers also warn of a long tail of incidents, since many embedded and unmaintained PHP installations will never be patched.

It is important to separate reported exploitation attempts from confirmed breaches. But once exploit details are public, the time available to fix exposed systems shrinks fast, so do not wait for evidence of a successful attack. CERT-EU advises patching affected assets immediately and, where that is not feasible, consider isolating internet-facing applications until the fix is applied and verified.

Why PHP2Shell Is a Serious Business Risk

The severity comes from the combination of possible unauthenticated access, the sheer reach of PHP and the chance of taking over the underlying server. Depending on the PHP process’s privileges and your existing controls, the consequences can include:

• Web server and application compromise: altered site behavior, malicious scripts, or a foothold for further attacks
• Exposure of sensitive data: customer information, credentials, tokens and API keys reachable from the affected environment
• Malware and ransomware deployment: defacement, malicious file hosting, or a staging ground for ransomware
• Business disruption: downtime of websites, transactions and customer portals during containment and recovery
• Compliance and reputational damage: regulatory obligations, contractual consequences and loss of customer trust

Three things set this apart from a routine patch cycle. It is not an application bug, so secure code alone does not protect you. It can be exploited before authentication. And the window is short, because exploit details are public and unpatched, forgotten installations will remain targets for months.

How Organizations Should Respond to PHP2Shell: A Seven-Step Plan

1. Identify every PHP installation

Build an inventory of PHP runtimes across production and development servers, virtual machines, containers and images, CI/CD pipelines, hosting control panels, managed hosting, APIs, third-party products that embed PHP, and legacy applications with no active owner. An incomplete inventory leaves vulnerable systems exposed even after the main servers are patched.

2. Prioritise high-risk systems

Rank systems by internet exposure, business criticality, data sensitivity and runtime configuration. Start with internet-facing systems, especially those on Apache mod_php, and business-critical applications that handle sensitive data. If a system cannot be patched promptly, assess whether temporary isolation from public networks is necessary and feasible.

3. Apply security updates

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s patched package. Then:

• Restart Apache, PHP-FPM and any long-running PHP workers, and confirm the version running in production, not just the one installed on disk.
• Check that hosting providers, container platforms and OS vendors have supplied packages that contain the fixes.
• Review memory_limit and post_max_size afterwards. The fix adds a new hard memory limit, and reaching it ends the process without running shutdown handlers.
• If you rely on the volunteer-maintained rpms.remirepo.net repository, switch to distribution packages or build from source, because it did not have updates on release day.

4. Address unsupported PHP versions

Migrate PHP 8.1 and earlier to a supported branch or confirm that a trusted vendor has issued a backported fix for your exact environment. Document any remaining exposure, assign an owner and set a remediation deadline. An unsupported system is not safe just because it is hard to update.

5. Use interim mitigations only as a stopgap

Only updating fully fixes these flaws. The measures below reduce exposure to specific attack paths and do not make a server safe. Do not substitute a configuration change or a web application firewall rule for a verified update.

A cloud WAF, such as the rules Cloudflare has deployed for known exploit vectors, can add a layer of protection, but Cloudflare itself calls this a stopgap. If even these steps are not possible, CERT-EU and the UK NCSC advise considering taking the affected system off the public internet until it is fixed and verified.

6. Investigate possible compromise

Patching closes the vulnerability but does not tell you whether an attacker got in first. Review logs and telemetry for:

• Unusual, oversized or malformed HTTP and multipart requests, followed by memory-limit errors or repeated HTTP 500 responses
• Abnormally large PHPSESSID response cookies
• Repeated out-of-memory or fatal errors, worker crashes and unexplained service restarts
• Unexpected new or modified PHP files and unfamiliar processes
• Suspicious outbound network connections

These indicators are not proof of exploitation, but they help guide an investigation. If you suspect a compromise, preserve logs and volatile evidence before patching or restarting, then follow your incident response process to contain, scope and recover. Because worker memory can be read, also consider rotating secrets that may have passed through an exposed PHP process, such as API keys, tokens and database credentials.

7. Validate remediation and keep visibility

Confirm that every identified asset runs a fixed package and that services are restarted. Recheck containers, deployment pipelines and managed environments so vulnerable images are not redeployed, then update your asset inventory and document exceptions. Searchlight Cyber has released an open-source php2shell-scanner that tests whether a host is exposed; use it only on systems you own or are authorized to test. A good outcome shows not only that a patch was installed, but which assets were exposed, whether they may have been compromised and what residual risk remains.

Why PHP2Shell Reinforces the Need for Layered Application Security

PHP2Shell shows that a secure application does not necessarily run on a secure environment. Application testing can find weaknesses in authentication, authorization, input validation and business logic, but flaws in the runtime, server configuration, dependencies and deployment infrastructure open additional attack paths. Application security should therefore be layered:

• Vulnerability assessment: identifying known vulnerabilities and exposed assets across applications and infrastructure
• Penetration testing: validating weaknesses and realistic attack paths within an authorised scope
• Configuration review: examining web servers, PHP settings, access controls and deployment environments
• Dependency and runtime management: tracking what your applications depend on and keeping it supported and patched
• Incident readiness: monitoring, evidence preservation and response procedures for suspected compromise

For PHP2Shell specifically, scanning and penetration testing can establish exposure and validate controls, but they do not replace runtime patching. Any exploitation testing should be authorized, carefully scoped and run against a controlled environment.

How CyRAACS can help

Responding to a critical vulnerability takes more than identifying a CVE and applying a patch. You need visibility into your technology landscape, a clear remediation strategy and confidence that the fixes worked. CyRAACS helps organisations move from “we think we are patched” to “we have verified that we are”:

• PHP environment discovery and exposure assessment: find hidden or undocumented PHP runtimes across servers, containers, hosting panels and third-party applications, and establish remediation priorities
• Vulnerability assessment and penetration testing: evaluate custom and third-party PHP applications and their supporting infrastructure for misconfigurations and exploitable attack paths
• Patch prioritisation and remediation support: prioritise critical fixes, build structured upgrade paths, coordinate remediation and verify that patches are effective
• Compromise assessment and monitoring guidance: investigate indicators of compromise, analyse logs and strengthen monitoring, following an evidence-preserving incident response process where an incident is suspected

PHP2Shell is a timely reminder that vulnerability management must cover the whole application stack, including runtimes, infrastructure and third-party components. CyRAACS takes a structured, risk-based approach to identifying exposure, prioritising remediation and strengthening application security.

Concerned that your PHP environment may be exposed? Don’t wait for a breach. Contact CyRAACS to schedule a PHP exposure assessment, vulnerability assessment or penetration test tailored to your environment.

FAQs

What are CVE-2026-109618 and CVE-2026-109619? They are two critical PHP vulnerabilities, collectively known as PHP2Shell, that can allow remote code execution. One involves memory corruption during out-of-memory handling; the other involves stale internal global state.

How severe is PHP2Shell? Both vulnerabilities score 9.2 on CVSS v4.0, which is Critical.

Which PHP versions contain the fixes? PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Also check your vendor’s advisories for backported fixes.

Can a secure WordPress or Laravel application still be affected? Yes. PHP2Shell affects the underlying PHP runtime, so updating application code alone does not fix it. Check and update the runtime separately.

Are temporary configuration changes enough? No. Interim mitigations reduce exposure to specific attack paths but do not fully address both vulnerabilities. Updating to a verified fixed release is the only complete remediation.

Should we investigate systems that are already patched? Yes, if they were previously exposed and exploitation is a reasonable concern. Patching stops continued exposure but does not rule out an earlier compromise.

How can CyRAACS help? CyRAACS supports PHP environment discovery, exposure assessment, vulnerability assessment and penetration testing, patch prioritisation, remediation validation and compromise assessment.