PHP2Shell (CVE-2026-109618 & CVE-2026-109619): Critical PHP RCE Flaws, Affected Versions, and How to Fix Them

[Update] October 27, 2026: CISA Adds PHP2Shell Flaws to KEV Catalog, SOCRadar found a weaponized PHP2Shell toolkit on an extortion operator’s exposed server.

[Update] October 26, 2026: Unit 42 has retracted its October 23 report tying a European government agency intrusion to PHP2Shell. The flaws remain critical, and patching is still required.

[Update] October 23, 2026: Exploitation attempts began on October 17, four days before PHP released fixes. SOCRadar found PHP2Shell exploit tooling on an exposed attacker server. PHP releases new patches.

[Update] October 21, 2026, 14:00 UTC: PHP has released fixes for both vulnerabilities.

PHP2Shell is the name researchers now use for two critical vulnerabilities in PHP, the server-side language behind WordPress, Drupal, Magento, Laravel, and many custom web applications. Tracked as CVE-2026-109618 and CVE-2026-109619, both flaws reportedly allow Remote Code Execution (RCE), and the PHP security team rated each 9.2 on CVSS v4.0.

The flaws surfaced ahead of schedule. Their existence was leaked on October 20, 2026, two days before a coordinated disclosure, and the PHP security team responded that evening with an advance notice of an upcoming security release set for October 21, 2026, at 14:00 Coordinated Universal Time (UTC).

Before you continue: quickly check whether your domains are exposed with SOCRadar’s free PHP2Shell Checker.

PHP2Shell at a Glance

Attribute	Details
CVE ID	CVE-2026-109618, CVE-2026-109619
CVSS	9.2 CVSS v4.0 for each (PHP security team)
Affected Products	PHP
Affected Versions	All PHP installations serving web requests on releases before the fixed versions, including end-of-life branches
Fixed In	8.5.12, 8.4.27, 8.3.36, and 8.2.35; source backports for 8.1, 8.0, and 7.4
Exploitation Status	Added to CISA’s KEV catalog on October 26, 2026 (FCEB due date: October 29, 2026). Initial in-the-wild exploitation reported by Amazon. SOCRadar found PHP2Shell exploit tooling.
Patch Available	Yes, released October 21, 2026 at 14:00 UTC
Discovered By	Wiz Research (see question 8 for details)

PHP2Shell Timeline

PHP Releases Patches for PHP2Shell

On October 21, 2026, PHP released 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix both PHP2Shell vulnerabilities. Its security advisory confirms that the flaws can allow unauthenticated remote code execution and urges all PHP users to update immediately.

CVE ID	Advisory	What Goes Wrong
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	RCE via out-of-memory corruption: when memory runs out mid-request, PHP can be interrupted while internal request data is only partly set up, and cleanup may then treat that broken data as valid
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	RCE via stale global state: internal state tied to a request can outlive its freed memory, and a later request on the same worker may use it before it is reset

PHP rates the risk highest for Apache with mod_php, where it describes a demonstrated exploit that lets an unauthenticated request trigger the attack before any application code runs. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed deployments are also at risk.

PHP Warns of Another Unpatched Session Flaw

On October 23, 2026, PHP disclosed CVE-2026-115560, a separate session-handling flaw that the October 21 releases do not fix. It affects only applications that switch session.serialize_handler from php_binary or php_serialize to php with ini_set() before calling session_start(), while session upload progress is enabled. PHP considers this setup unlikely in practice. No exploitation has been reported, and no severity score has been published yet. The fix will ship in PHP’s next routine bugfix release.

Recommended action: Set session.upload_progress.enabled=0, the same mitigation PHP issued for CVE-2026-109619. Organizations that have already applied it need to do nothing more. Upgrading to the October 21 releases is still required to fix CVE-2026-109618 and CVE-2026-109619.

CISA Adds PHP2Shell Flaws to KEV Catalog

CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on October 26, 2026. Federal Civilian Executive Branch (FCEB) agencies have until October 29, 2026 to remediate, a three-day window.

The listing comes after a security researcher’s honeypot findings from October 24, 2026, which reported successful remote code execution (RCE) against three honeypots running PHP 8.4.26. The researcher described the result as confirmed RCE with usable memory disclosure, and the activity is consistent with CVE-2026-109618. The test used a deliberately favorable single-worker mod_php setup, so it does not measure exploit reliability against other worker counts, PHP builds or applications. Separate analysis cites reports of working exploits against unpatched PHP 8.2 through 8.5.

The fix has not changed: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your vendor’s backported package. Organizations outside the federal mandate can use the October 29 deadline as a benchmark for their own patching.

1. What Is PHP2Shell?

PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that researchers say let a remote attacker run code on a server running PHP. The name points to the expected result, a shell on the target.

Because the fix ships in PHP itself, protection for WordPress, Drupal, Magento, and other PHP applications depends on updating the server’s PHP version. Updating the application alone does not close the gap.

2. How Did PHP2Shell Become Public Before the Patch?

PHP2Shell became public through a leak. On October 20, 2026, details surfaced claiming that two PHP RCE flaws, rated critical and affecting every version since PHP 5, would be disclosed on Thursday, October 22, 2026. watchTowr then confirmed on X that the flaws were real and under embargo, and urged users to apply patches once available.

3. How Severe Are CVE-2026-109618 and CVE-2026-109619?

The PHP security team rates both flaws 9.2 on CVSS v4.0, which is critical severity. PHP’s advisory traces CVE-2026-109618 to out-of-memory handling and CVE-2026-109619 to stale global state, and confirms that both can be exploited without authentication.

CERT-EU, the cybersecurity service for European Union institutions, says the 9.2 scores point to possible unauthenticated RCE.

4. Which PHP Versions Are Affected by PHP2Shell?

PHP released fixes for both vulnerabilities on October 21, 2026. Affected releases in supported branches are PHP 8.5 before 8.5.12, PHP 8.4 before 8.4.27, PHP 8.3 before 8.3.36, and PHP 8.2 before 8.2.35. Older, end-of-life branches are also affected.

The table below lists the fixed releases and available source backports:

Branch	Fixed Version	Support Status
8.5	8.5.12	Active support until December 31, 2027
8.4	8.4.27	Active support until December 31, 2026
8.3	8.3.36	Security fixes only until December 31, 2027
8.2	8.2.35	Security fixes only until December 31, 2026
8.1, 8.0, 7.4	Minimal source backports only	End of life
7.3 and older	No fix from PHP	End of life

5. Will End-of-Life PHP Versions Get a PHP2Shell Fix?

Not through regular releases. PHP 8.1 and older no longer receive official updates, but given the severity, PHP’s security team published minimal source backports for PHP 7.4, 8.0, and 8.1 for anyone building from source. Some distributions and long-term support (LTS) vendors also ship backported fixes, but upgrading to a supported branch remains the only lasting remedy.

Shodan lists around 884,000 internet-facing hosts running PHP 8.1 or older. An additional 740,000 hosts run PHP without specifying a version number.

6. How to Check If Your Site Is Vulnerable to PHP2Shell?

Use SOCRadar’s free PHP2Shell Checker to check the PHP version exposed by your domain against the fixed releases. The tool uses passive signals such as response headers and flags end-of-life branches. It requires no signup or agent and does not attempt exploitation.

An inconclusive result does not mean your site is safe. If the version is hidden, confirm the PHP runtime through your hosting panel or server administrator.

On the server, php -v checks the command-line installation, which may differ from the PHP runtime serving web requests. Verify the web runtime separately and consult your distribution’s security advisory, since vendor packages may include backported fixes without changing the upstream version number.

Vendor Products Affected by PHP2Shell

PHP2Shell also reaches network appliances and products that bundle PHP. Vendor advisories as of October 22 and 23 report the following:

• Palo Alto Networks: PAN-OS 12.2, 12.1, 11.2, 11.1 and 10.2 and all Panorama versions are affected, with no fixed release yet. Interim steps are Threat Prevention signatures (Threat IDs 543004 and 97622 to 97625), moving management traffic off the management port and restricting management access. Palo Alto Networks is not aware of malicious exploitation.
• Cisco: Expressway and Expressway Select (CSCwx37062) are rated Critical, with 15.5.21 listed as the fixed release and no workaround. Snort rules 67359 and 67360 are available. Ultra-Reliable Wireless Backhaul (CSCwx37073) is also affected. ISE Portal Builder, Catalyst Center and WAE are under investigation.
• Fortinet: FortiADC Manager, FortiClient Cloud Services, FortiDDoS and FortiDDoS-F are under investigation.
• Splunk: No affected products are confirmed so far. OnCall, AppDynamics SaaS and Smartlook are under investigation.

7. Is PHP2Shell Being Exploited in the Wild?

Yes. Exploitation attempts started before the patches were released. Amazon threat intelligence reported that the first attempts began on Saturday, October 17, four days before PHP shipped fixes. The attempt came from an IP address associated with a commercial anonymization network and targeted a honeypot, which suggests a threat actor was behind it. How that actor got exploit information before disclosure is still unclear.

Multiple PoC exploits were deployed from VPN IP addresses within hours of disclosure. Payloads and anonymization infrastructure varied, which points to multiple actors. Amazon now describes the flaws as broadly exploited in the wild, but it is unclear how many attacks succeed. Its guidance for defenders is direct: do not assume the public disclosure date is the earliest date of exploitation.

Several other security firms also detected unsuccessful exploitation attempts before public disclosure. Honeypot data recorded exploitation of both CVE-2026-109618 and CVE-2026-109619 on October 21. Other threat intelligence reporting describes observed activity as limited to scanning, fingerprinting and non-working exploits, with no known compromises. That reporting also warns that working PoCs or successful exploitation are only a matter of time.

Some PoC exploits were published before the patches, and PHP said none of them were functional. PHP core developer Gina Peter Banyard said applying the official patches is the only permanent defense. The UK National Cyber Security Centre (NCSC) has told UK organizations to update PHP servers immediately or take them offline until they can be patched.

On October 21, CISA said it had not observed exploitation. CISA added both CVEs to the KEV catalog on October 26, 2026, with an October 29, 2026 due date for FCEB agencies.

The exposure is large. PHP powers up to 80% of websites. More than 5.1 million PHP hosts are tracked as exposed online, and about 3.8 million of them have at least one port open to attack.

A Retracted Government-Agency Compromise Claim

On October 23, 2026, Unit 42 reported post-exploitation activity it initially linked to PHP2Shell, describing an intrusion at a European government agency run through a vulnerable PHP application. On October 25, that report was retracted, saying the researchers could not confirm the attacker’s initial access came from CVE-2026-109618 or CVE-2026-109619.

What SOCRadar Sees on the Dark Web

Concern about PHP2Shell has also reached the Dark Web. Some underground forums, such as BreachForums and Dread, have taken their sites offline as a precaution.

Hacker forums also show interest in a working exploit. In one PHP2Shell thread, a user asked others to share an exploit, noting the one they found did not work on all versions, and another said they were eager to start compromising servers.

PHP2Shell Exploit Tooling Found on an Exposed Attacker Server

SOCRadar researchers found PHP2Shell exploit tooling on an attacker-controlled server. The server’s working directory had an open, unauthenticated directory listing, and all files were collected passively.

• aslr_exploit.py: A one-click exploit for PHP 8.4.26 under Apache mod_php, the last vulnerable 8.4 release. It recycles the PHP worker, leaks memory addresses through the session cookie to defeat ASLR, and abuses session upload progress handling to run a shell command. It defaults to a local target, which suggests testing against containers the operator controls
• Preconditions: Visible PHP errors, session upload progress enabled, session strict mode disabled, a very low memory limit and a single Apache worker
• Limitation: The payload only runs a very short command, so a real attack would need a second-stage script
• Screening scripts: php2shell_fp.py checked about 20 sites for PHP versions and session echo. deep_probe.py examined 11 sites for displayed errors, phpinfo pages, file inclusion and session injection. wp_attack.py enumerated users, plugins and XML-RPC methods on five WordPress sites. All traffic went through a rotating proxy pool on the same server

Six of the 11 probed sites ran PHP 8.4 releases older than the fix, four of them on 8.4.26. None met the exploit’s preconditions. SOCRadar assesses with moderate confidence that the tooling targets CVE-2026-109618. There was no evidence of shell access on any screened site as of October 22. The operator is unattributed, and the motivation appears financial, given other files pointing to activity against financial and Web3 targets.

The hardened settings that blocked this chain will not stop every variant. Updating PHP remains the fix.

8. Is There a Public PHP2Shell Exploit or Proof-of-Concept (PoC)?

Researchers have demonstrated exploitation of both vulnerabilities. Wiz published its research alongside PHP’s patches, and Datadog independently reproduced the flaws. PHP’s advisory also described demonstrated exploitation against Apache with mod_php.

As of October 24, exploitation has been reported against honeypots, and separate reports describe working exploits against unpatched PHP 8.2 through 8.5.

9. How Did Researchers Discover and Exploit PHP2Shell?

Wiz researchers published their official write-up alongside PHP’s patches. The team says frontier AI models helped find the bugs and chain them into working exploits, and compares PHP2Shell’s potential reach to Heartbleed and Log4Shell. Here’s a quick look at the write-up:

• Root cause: There are four bugs behind the two CVEs, which stem from how PHP handles fatal out-of-memory errors mid-request, which can leave stale internal state for a later request to reuse. PHP’s patch fixes the issue at its source, covering other variants too.
• Demonstration: The team chained the bugs into one exploit that ran code without authentication on out-of-the-box WordPress, Drupal, and Joomla deployments. Separately, it showed attackers can read PHP worker memory holding data such as passwords and API keys.
• Hunting signals: The write-up lists signs to watch for, such as unusual multipart requests followed by memory-limit errors or repeated 500 responses, and oversized or malformed PHPSESSID cookies.
• Disclosure timeline: The first bug was found on August 19, 2026, reported to PHP on August 24, 2026, and acknowledged by PHP on September 21, 2026.

10. How Fast Could Attackers Exploit PHP2Shell After the Patch?

Attackers could move within minutes, because published fixes show where the bugs are.When CVE-2024-4577, a flaw in PHP’s Common Gateway Interface (CGI) mode on Windows, became public in June 2024, Akamai saw exploit attempts against its honeypots within 24 hours.

11. PHP2Shell Workarounds: What Helps and What Doesn’t

No complete workaround exists, and PHP calls updating the only safe choice. For servers that cannot be updated immediately, PHP’s advisory lists configuration measures that reduce exposure to specific attack paths without making an installation safe:

• CVE-2026-109618: Set memory_limit=-1 in a way applications cannot override, lower post_max_size (8M without file uploads, 32M with them), enforce request size and count limits at the web server or proxy, and use container or cgroup limits instead of RLIMIT_AS or RLIMIT_DATA.
• CVE-2026-109619: Set session.upload_progress.enabled=0 in php.ini or server configuration and restart every worker, set fatal_error_backtraces=0 on PHP 8.5, remove invalid per-request settings that emit diagnostics, and fix attacker-reachable fatal errors and timeouts.

CERT-EU also advises considering isolating internet-facing applications from public networks until a fix is applied.

Disabling session.upload_progress.enabled alone does not fully protect against PHP2Shell. These configuration changes reduce exposure to specific attack paths; they do not replace patching.

A web application firewall can filter some malicious requests before they reach PHP, but protection depends on rule coverage and whether traffic can bypass the WAF. Treat it as a temporary measure.

12. How Can Security Teams Detect PHP2Shell Exploitation?

Monitor both request-processing anomalies and post-exploitation behavior. Look for unusual form submissions, memory-exhaustion errors during request initialization, repeated server errors, and malformed PHPSESSID cookies. Correlate these signals with process activity, since individual errors do not establish exploitation.

Alert when php-fpm, php-cgi, httpd, or apache2 unexpectedly launch shells, script interpreters, or download tools such as curl and wget.

If an alert fires, isolate the server, preserve web server and PHP logs, and hunt for web shells, new files in the web root, new cron jobs or scheduled tasks, and unexpected accounts.

PHP2Shell Indicators of Compromise

Indicator	Type	Context
206.188.197.105	IPv4	Attacker staging and operations server
Port 9999	Port	Exposed operator working directory (HTTP directory listing)
Port 8899	Port	Rotating proxy pool endpoint
Port 8888	Port	Out-of-band interaction listener
MARKER_[8 hex characters].txt	Upload filename	Session injection screening probe
fprint, dp	Session ID prefixes	Upload-progress screening probes

Detection additions

• Block 206.188.197.105 at the perimeter and search web and proxy logs for past connections
• Hunt for multipart POSTs containing PHP_SESSION_UPLOAD_PROGRESS from unfamiliar sources, especially uploads named MARKER_ followed by eight hex characters
• Set expose_php=Off to stop version disclosure in response headers
• Treat activity from before October 21 as in scope when reviewing logs, since exploitation attempts began on October 17

13. How Can SOCRadar Help Track PHP2Shell Exposure?

With fixes available and exploitation reported, organizations need to identify exposed PHP installations, prioritize patching, and monitor for signs of compromise.

SOCRadar can support that process through:

• Attack Surface Management: Helps identify internet-facing assets running PHP and prioritize exposed systems, including those on end-of-life branches, for patching or isolation.
• Vulnerability Intelligence: Tracks severity, exploitation developments, KEV status, and affected and fixed versions for CVE-2026-109618 and CVE-2026-109619.
• PHP2Shell Checker: Provides a free external version check to help identify domains that need further verification or patching.

Combining external asset visibility with vulnerability intelligence can help security teams find exposed PHP servers quickly while patching and compromise assessment proceed.

14. How to Patch PHP2Shell

Update the PHP runtime serving your application to a fixed upstream release or a verified vendor-patched package. Prioritize internet-facing systems, then update internal installations:

• Inventory every install: Include PHP bundled in vendor appliances, Windows software, and hosting control panels such as cPanel and Plesk.
• Update now: Move to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, internet-facing systems first, then restart the PHP FastCGI Process Manager (PHP-FPM) or web server so the new build loads.
• Check backports: Consult your distribution or hosting provider’s advisory and install the package containing the fix. Version numbers alone may not identify backported patches.
• Rebuild containers: Update the PHP base image, rebuild and redeploy affected containers, and replace workers still running the old runtime.
• Restrict unpatched systems: Remove public access or restrict access through a VPN or allowlist until patched. WAF rules provide supplementary protection.
• Verify and monitor: Confirm the web-serving runtime uses a fixed release or patched vendor package. Review logs for earlier compromise and monitor PHP workers for unexpected child processes.

Frequently Asked Questions About PHP2Shell

What Is PHP2Shell?

PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in PHP that can allow unauthenticated remote code execution. Each has a CVSS v4.0 score of 9.2.

Which PHP Versions Fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the fixes. Vendor packages may also include backported patches, so check your provider’s security advisory.

Is WordPress Affected by PHP2Shell?

Yes, WordPress sites can be affected when their underlying PHP runtime is vulnerable. Updating WordPress or its plugins alone does not fix PHP; your hosting provider or administrator must update the runtime.

Does Disabling session.upload_progress Fix PHP2Shell?

No. Disabling session.upload_progress.enabled may reduce exposure to a specific attack path, but it does not fully address both vulnerabilities. Patching remains necessary.

Does a WAF Protect Against PHP2Shell?

A WAF may block some exploitation attempts, but it cannot guarantee protection against every variant or traffic that bypasses it. Use it as a temporary supporting control while patching.

Is PHP2Shell Being Exploited?

Yes. Security vendors have reported exploitation activity. Distinguish confirmed compromise from scanning and attempted exploitation when assessing individual reports.

How Do I Check Whether My Site Is Vulnerable?

Start with SOCRadar’s PHP2Shell Checker, then verify the PHP runtime serving your website. An inconclusive external result does not establish that the site is safe.

Who Discovered PHP2Shell?

Wiz Research reported discovering the vulnerabilities and published its technical analysis alongside PHP’s patches. Its research describes using AI models to help identify bugs and develop demonstrations.

When Did PHP2Shell Exploitation Start?

The first exploitation attempts were observed on October 17, 2026, four days before PHP released fixes on October 21. Several security firms also detected unsuccessful attempts before public disclosure. Log reviews should cover the period before the patch date.

Is PHP2Shell in CISA’s KEV Catalog?

Yes. CISA added CVE-2026-109618 and CVE-2026-109619 to the KEV catalog on October 26, 2026, and FCEB agencies must remediate by October 29, 2026.

Are Firewalls and Network Appliances Affected by PHP2Shell?

Some are. Palo Alto Networks PAN-OS and Panorama are affected, with no fixed release yet. Cisco Expressway is rated Critical. Other Cisco, Fortinet and Splunk products are under investigation. Check each vendor’s advisory, since a product missing from a list is not confirmed safe.