PHP2Shell (CVE-2026-109618 and CVE-2026-109619): What It Is, Who Is Affected, and How to Fix It

Vulnerability Alert
October 30, 2026

PHP2Shell is the name the security community has given to two critical unauthenticated remote code execution vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619. Each has a CVSS v4.0 score of 9.2. Exploitation began at least four days before public disclosure, proof-of-concept code appeared before the patch was released, and CISA added both CVEs to its Known Exploited Vulnerabilities catalog within five days of the fixes going public. If your environment runs PHP in any form, patching is not optional.

This guide covers what php2shell is, how the two flaws work, the full exploitation timeline, how many servers are exposed, and exactly what each role in your organization needs to do right now.

What Is PHP2Shell? (The 60-Second Answer)

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) are two critical unauthenticated remote code execution vulnerabilities in PHP core, each rated CVSS 9.2. They affect all PHP SAPIs, including mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed, across every version since PHP 5. Fixed versions (PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12) were released October 21, 2026. Exploitation was confirmed before public disclosure. Patching is the only complete fix.

PHP powers 69.2% of all websites that use a known server-side programming language.[8] WordPress, Drupal, Joomla, Magento, and hundreds of vendor appliances run on it. That ubiquity is precisely what makes PHP2Shell different from most critical CVEs. Palo Alto Networks’ Cortex Xpanse data puts the number of exposed PHP instances at approximately 22 million.[5] For comparison, recent critical NetScaler vulnerabilities exposed roughly 50,000 instances, while BeyondTrust CVE-2026-1731 exposed roughly 16,000. PHP2Shell is operating at a fundamentally different scale.[5]

A patch is available. The key question is whether your organization has installed it, and whether your window is already closing.

CVE-2026-109618 and CVE-2026-109619: What the Flaws Actually Do

PHP2Shell has two distinct vulnerabilities, not one. They target different stages of PHP’s request life cycle, but both allow an unauthenticated attacker to execute arbitrary system commands with a single malformed HTTP request, before any application code runs, and therefore before any application-layer authentication can intervene.[3]

CVE-2026-109618, Out-of-Memory Use-After-Free

PHP uses a longjmp() call when it encounters an out-of-memory (OOM) error, abandoning the current execution context to abort request handling. Some code paths within PHP do not correctly account for this scenario: they leave request memory in an uninitialized state before performing an allocation. When PHP then executes its normal request cleanup, it may read from or branch on this uninitialized memory. Multiple OOM-triggering strategies can exploit this condition consistently and produce remote code execution.[7]

In practice, an attacker crafts a multipart POST request that forces an OOM condition during parsing, before any PHP application code runs. The attacker’s command executes during the cleanup phase of the aborted request. Datadog’s research team independently reproduced this on PHP 8.5.11 with a single unauthenticated HTTP POST. Critically, any PHP script exposes this path; there is no need to target a specific vulnerable page.[3]

CVE-2026-109619, Stale Global State Use-After-Free

PHP maintains various global state structures that temporarily point into request-specific memory. Under certain conditions, that global state is not correctly reset, or is repopulated after being reset. When a subsequent request arrives, PHP may read from or branch on this stale state, which now points into memory that has already been freed from the previous request. Multiple strategies can trigger this to produce remote code execution.[7]

This flaw is connected to PHP’s session upload progress handling and multipart request parsing, both of which are enabled by default. This means the attack surface is not limited to applications that deliberately use file upload features, it is every PHP installation that serves web requests.[1]

Why authentication does not help

CISA, Datadog, and the PHP Foundation all confirm the same point: application-level authentication cannot block either attack. PHP processes the malicious request, and the exploit triggers, before your application’s login check or session validation has any chance to run.[3][2] Configuring authentication on your PHP application is good security hygiene, but it provides no protection against PHP2Shell.

PHP2Shell Timeline: Discovery, Leak, and Exploitation Before the Patch

PHP2Shell followed an unusual disclosure timeline. Information about the flaws became public before the patch was ready, and attackers had already been observed trying to exploit them four days before public disclosure.

Two lessons from this timeline apply beyond this specific vulnerability. First, the public disclosure date is not the earliest possible date of exploitation. AWS explicitly advises organizations to begin incident investigations from October 17, 2026, not October 21.[4] Second, AI-assisted exploit development is compressing the patch-to-exploit window. Working proof-of-concept code appeared before the official patch dropped. The seven-day or 30-day patch SLA that many organizations use is structurally unsafe for critical internet-facing vulnerabilities in the current environment.[4][5]

How Many PHP Servers Are Exposed to PHP2Shell?

PHP2Shell stands out because of the sheer number of potentially exposed systems.

Palo Alto Networks’ Cortex Xpanse data puts the number of exposed PHP instances at approximately 22 million.[5] By comparison, recent critical NetScaler vulnerabilities exposed roughly 50,000 instances and BeyondTrust CVE-2026-1731 exposed roughly 16,000. PHP2Shell is operating at three orders of magnitude larger scale.[5]

Shodan banner analysis published by Mallory on October 20, 2026 counted approximately 2.24 million internet-facing hosts advertising PHP.[6] Of the roughly 1.5 million that disclosed their version, 59%, approximately 883,717 hosts, run a PHP branch for which no official release exists: the PHP project has no patch available for these versions.[6]

CybelAngel scanned 1.3 million internet-facing assets after the patch release and found that 54% of sites that disclosed their PHP version run an end-of-life branch.[6]

The version breakdown among internet-facing versioned hosts:

Source: Shodan banner data, Mallory, October 20, 2026.[6]

Here is what these numbers mean for your organization: If your PHP installation runs version 8.2 or above, a patch exists and you must apply it. If it runs 8.1 or below, the PHP project has no official release for your version. You need either a Linux distribution backport (Debian, Ubuntu, and RHEL all provide these, check your distribution’s security advisory), an upgrade to a supported branch, or immediate restriction of that system’s internet exposure until it can be remediated.

Which PHP Versions Are Affected and What Are the Fixed Releases?

Sources: PHP Foundation[1]; CybelAngel[6]; CISA[2]

Important notes:

• Being on a supported branch is not enough. You must be running the specific patched version number.
• Linux distributions package PHP with their own version numbering. Run php -v on the running instance, not just on the binary, as the version serving web requests can differ from what php -v returns on the command line.[6]
• Shared hosting and managed platforms may apply patches independently. Confirm with your provider and verify the version actively in use.
• PHP 8.2 reaches its official end of life on December 31, 2026. Begin planning your migration to PHP 8.3, 8.4, or 8.5 now.

To verify your current version across all servers, see our guide on how to check your PHP version. For step-by-step update instructions, see the php2shell patch guide. If your environment includes PHP 7.4 deployments, see our PHP 7.4 end of life guide.

Not sure if your servers are patched? SureShield’s PHP vulnerability scan identifies every internet-facing PHP instance across your environment, flags unpatched versions, and prioritises by risk.

Scan My PHP Servers →

PHP2Shell Response Plan by Role

PHP2Shell is not a single action item, it involves security, operations, compliance, and development teams working in parallel. Here is what each role is responsible for, and when.

A note for federal agencies: CISA added both CVEs to its KEV Catalog on October 26, 2026 under BOD 26-04, with a required remediation deadline of October 29, 2026, just three days after catalog inclusion, and one of the shortest CISA KEV windows on record.[9] For detailed compliance implications for CMMC and NIST 800-171, see our CISA KEV deadline guide. Healthcare organizations should consult our HIPAA vulnerability management article. MSPs managing multiple client environments should see our MSP vulnerability management playbook.

Temporary Mitigations While You Patch, and Their Limits

Updating PHP is the only complete fix for PHP2Shell. This is confirmed explicitly by PHP,[1] CISA,[2] Datadog,[3] and AWS.[4] No configuration change, no WAF rule, and no PHP.ini setting fully addresses both CVEs in all attack scenarios simultaneously.

Some temporary measures can reduce exposure while patching is underway. However, each has important limitations, explained below.

WAF rules, partial coverage for known attack paths

Cloudflare, F5, AWS WAF, and other vendors released emergency WAF rule updates on October 21, 2026. These rules block known exploit payloads targeting documented attack paths but cannot anticipate all exploit variations. They also do not protect PHP-FPM deployments that are not fronted by a WAF, and they provide no coverage against novel patterns. Use WAF protection as a temporary bridge while you patch, not as a replacement for patching.

Disabling session.upload_progress in PHP.ini, insufficient on its own

Setting session.upload_progress.enabled=0 is the most widely circulated mitigation. It does not fully protect against PHP2Shell. Datadog independently tested and confirmed that this setting does not prevent exploitation in all documented attack paths for CVE-2026-109618.[3] PHP itself states there are no complete mitigations and that updating PHP is the only safe choice.[1] Do not use this as a substitute for patching.

Restricting POST size and blocking multipart requests, reduces exposure, not a fix

Limiting post_max_size, upload_max_filesize, and blocking multipart/form-data content types can reduce the attack surface for CVE-2026-109618. These measures may break legitimate application functionality. The PHP Foundation and F5 both note they do not address all documented OOM techniques and do not constitute a complete fix.[7]

Taking PHP systems offline, appropriate where patching is delayed

CISA’s guidance for organizations that cannot immediately patch is explicit: take PHP-based systems offline until they can be patched or updated.[2] Taking systems offline is disruptive, but it is the appropriate choice when you cannot otherwise control their internet exposure.

Investigating for prior compromise

Because exploitation began October 17, 2026, log reviews must begin on or before that date. Run a php vulnerability scan to confirm which servers remain exposed, then review those systems for post-exploitation activity. Our detailed php2shell indicators of compromise guide covers what to look for.

PHP2Shell Compliance Implications: CISA KEV, BOD 26-04, CMMC, and HIPAA

PHP2Shell also has immediate compliance implications across several frameworks.

CISA Known Exploited Vulnerabilities (KEV)

CISA added CVE-2026-109618 and CVE-2026-109619 to its KEV Catalog on October 26, 2026.[9] Both entries carry a forensic triage indicator of “Yes,” meaning CISA considers them candidates for active investigation. This is not a routine advisory, it reflects confirmed exploitation in the wild.

Binding Operational Directive 26-04

Under BOD 26-04, all federal civilian executive branch (FCEB) agencies must remediate KEV entries within specified timeframes. For PHP2Shell, the required remediation deadline is October 29, 2026, three days after catalog inclusion. This three-day window reflects the severity of active exploitation and is one of the shortest deadlines in recent CISA KEV history.

CMMC / NIST 800-171

DoD contractors subject to CMMC Level 2 or Level 3 requirements must document and remediate this vulnerability. Applicable NIST 800-171 controls include AC-2 (account management for compromised accounts), RA-5 (vulnerability scanning), and SI-2 (flaw remediation). Organizations that cannot remediate within 30 days must document the gap in their Plan of Action and Milestones (POA&M). See our CISA KEV deadline guide for the full CMMC and NIST 800-171 analysis.

HIPAA

Covered entities and business associates running PHP on systems that store or process protected health information (PHI) face materially elevated breach risk from PHP2Shell. An unpatched, internet-facing PHP server constitutes an inadequately protected technical safeguard under 45 CFR § 164.312. See our HIPAA vulnerability management article for the specific obligations and documentation requirements.

CVE-2026-109619 and Memory Disclosure

One frequently overlooked dimension of PHP2Shell is that CVE-2026-109619’s stale global state condition can enable memory disclosure, including extraction of session identifiers such as PHPSESSID, that provides attackers with the memory layout information needed for more reliable subsequent exploitation.[3] For organizations subject to data protection obligations beyond mere server compromise, this broadens the impact scope significantly. For a full analysis, see our CVE-2026-109619 memory disclosure article.

For organizations running structured threat and vulnerability management programs, PHP2Shell is a direct test of whether your patch processes can operate in hours rather than days. If your current SLAs cannot meet that pace for critical internet-facing vulnerabilities, now is the right moment to revise them.

Managing vulnerabilities at scale? SureShield SecurityShield TVM helps teams track, prioritise, and remediate vulnerabilities like PHP2Shell across complex environments.

Explore SecurityShield TVM →

PHP2Shell Indicators of Compromise and Detection Guidance

Because exploitation began before public disclosure, your investigation timeline starts on October 17, 2026, not October 21. AWS MadPot telemetry identified the following IP addresses associated with PHP2Shell exploitation attempts:[4]

Important: AWS states these addresses include shared anonymization infrastructure. Organizations should investigate observations of these IPs rather than block them outright, blocking shared anonymization infrastructure may prevent legitimate traffic.[4]

Behavioral indicators to monitor:

• Web server processes (Apache, nginx, php-fpm) spawning unexpected shell processes (bash, sh, cmd)
• POST requests with PHP_SESSION_UPLOAD_PROGRESS in form field names
• Large or malformed multipart POST requests, particularly with unusual content-length relationships
• Memory exhaustion events during request initialization
• New PHP files in web root or upload directories not created by your deployment pipeline
• Unexpected outbound connections from web servers to unusual IPs or ports
• Modifications to existing PHP files (check file modification timestamps and hash values)

CISA has published SIGMA detection rules targeting PHP2Shell-related activity, available in its SIGMA Rules GitHub repository.[2] For a complete detection guide including log query templates and host-based indicators, see our php2shell indicators of compromise article.

Frequently Asked Questions About PHP2Shell

1. Is my WordPress, Drupal, or Magento site affected by PHP2Shell?

1. Yes, if it runs any PHP version on an affected branch without the October 21, 2026 patch applied. PHP2Shell is a vulnerability in PHP core, not in WordPress, Drupal, or Magento itself. Updating your CMS, its plugins, or its themes does not fix it. You must update PHP at the server level and restart the PHP-FPM or web server process to load the new binary. According to WordPress.org statistics, 35.1% of WordPress sites run a PHP version the PHP project no longer supports, including 16.46% on PHP 7.4.[6] See our php2shell WordPress guide for platform-specific patching instructions.

1. Does placing a WAF in front of my PHP application fully protect against PHP2Shell?

1. No. WAF rules can block known attack payloads for documented paths, but they cannot anticipate all exploit variations and do not address the underlying flaw. Datadog confirmed that application-layer controls, including WAF responses, cannot block PHP2Shell because PHP processes the malicious request before application code runs.[3] WAF rules can help temporarily, but they do not fix the vulnerability. Update PHP.

1. Will setting session.upload_progress.enabled=0 in PHP.ini protect against PHP2Shell?

1. No. This is the most widely circulated partial mitigation, but it does not fully protect against PHP2Shell. Datadog independently tested and confirmed that this setting does not prevent exploitation in all attack paths for CVE-2026-109618.[3] PHP itself states there are no complete configuration-based mitigations and that updating PHP is the only safe choice.[1]

1. When was PHP2Shell first exploited in the wild?

1. October 17, 2026. AWS MadPot honeypot telemetry recorded the first known exploitation attempt on that date, four days before public disclosure and before the patch was released.[4] If you are investigating a potential compromise, your log review must begin on or before October 17, not on October 21 when the patch was released.

1. What is the CISA deadline for patching PHP2Shell?

1. CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities Catalog on October 26, 2026.[9] For federal civilian executive branch agencies, the required remediation deadline under BOD 26-04 is October 29, 2026. Non-federal organizations are not legally bound by BOD 26-04 but CISA strongly urges immediate patching. CMMC and NIST 800-171 implications are covered in our CISA KEV deadline guide.

8. My PHP version is 8.1, is there a patch?

1. There is no official PHP release for PHP 8.1, which reached end of life before this disclosure. The PHP security team published minimal source backports for 7.4, 8.0, and 8.1, but these are intended for operators who build PHP from source, not for typical shared hosting or application deployments.[6] Check your Linux distribution’s security advisory (Debian, Ubuntu, RHEL, and similar vendors may provide backported packages), or upgrade to PHP 8.2, 8.3, 8.4, or 8.5. Until remediated, CISA recommends taking PHP-based systems offline.[2] See our PHP 7.4 end of life guide for migration paths.

1. Is PHP-FPM affected by PHP2Shell?

1. Yes. PHP-FPM is one of the named affected Server APIs (SAPIs). CISA’s alert explicitly lists PHP-FPM, mod_php (flagged as highest risk by PHP), php-cgi, FrankenPHP, and LiteSpeed as affected configurations.[2] All must be patched by updating PHP and restarting the relevant service so the patched binary is loaded into memory.

What to Do About PHP2Shell Right Now

PHP2Shell is an active security threat, not a hypothetical one. It was being exploited before the patch existed, proof-of-concept code circulated before the embargo lifted, and CISA classified it as actively exploited within five days of the patch going public. The only complete fix is to update to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12.

Start with these three steps, in this order:

1. Inventory. Find every PHP instance in your environment, including those embedded in third-party software, CMS platforms, and managed hosting accounts.
2. Patch. Update to the appropriate fixed version and restart PHP-FPM or the web server to load the new binary.
3. Investigate. Review logs from October 17, 2026 onward for signs of prior compromise.

If you do not have full visibility into your PHP estate, run a php vulnerability scan to find out what you are working with before attackers find the gaps for you.

Your servers are being scanned for PHP2Shell right now. Find out which are vulnerable before attackers do.

Start My Free PHP Scan →