Threat update • Controlled-honeypot RCE confirmed[13]
PHP2Shell now has packet-to-process proof of successful command execution on controlled honeypots.[13]
A researcher-operated honeypot report correlates 35 complete execution-stage HTTP requests with 35 Apache-parented shell starts across three disposable targets.[13] The report says the tested profile was intentionally favorable and does not measure exploit reliability across other worker counts, PHP builds or applications.[13]
Reporting cutoff: October 26, 2026 at 21:40:28 UTC. Status details can change after this time.
October 25 update
Palo Alto starts releasing PAN-OS hotfixes[12]
Palo Alto’s October 25 timeline says PAN-OS 10.2.18-h13, 11.1.16-h4 and 11.2.10-h16 are released.[12] These are branch-specific targets, not evidence that every PAN-OS branch or maintenance train is fixed.[12]
- Exposure: The vendor says PAN-OS risk is highest when the management interface is reachable from external internet IP addresses.[12] In that scenario, its CVSS 4.0 score is 8.7 High.[12]
- Configuration: Palo Alto says no special configuration is required to be affected.[12]
- Observed abuse: Palo Alto says it is not aware of malicious exploitation of this issue against its products.[12] That statement does not establish whether any specific customer was exposed or compromised.[12]
- Choose by exact train: Other maintenance trains remain tied to vendor-listed fix targets or estimates, so operators should use the target for the exact maintenance train they run rather than treating one released hotfix as universal coverage.[12]
Advisory caveat: The generic solution text still says PAN-OS fixes are upcoming, but the newer timeline and product matrix identify released builds and branch-specific fixed-version thresholds; for current release status, those newer structured fields are decisive.[12]
What the new evidence says
Amazon Threat Intelligence says its MadPot honeypot network recorded a PHP2Shell exploitation attempt on October 17, four days before public disclosure. It also reports more attempts between 02:00 and 08:00 UTC on October 21, followed by additional activity after the 14:00 UTC embargo lifted. Amazon’s wording is important: it calls the activity broad exploitation attempts in the wild, but says the success of the earlier attempts against real systems is unknown.[1]
Cloudflare separately says it observed attack traffic targeting customers and saw attackers mutate payloads while trying to bypass protections.[3] Cloudflare deployed managed WAF protections, including to its Free plan, but still tells customers to patch PHP because WAF rules are defense in depth rather than a replacement for the runtime fix.[3]
The PHP Group’s two published CVE records identify distinct remote-code-execution flaws: CVE-2026-109618 concerns out-of-memory corruption, while CVE-2026-109619 concerns stale global state retained across requests.[4][5] Both records carry a CVSS v4.0 score of 9.2 and list the same supported-branch fix boundaries.[4][5]
Confirmed on controlled targets
Packet-to-process evidence from controlled honeypots[13]
The primary report says 35 complete execution-stage HTTP POST requests correlated with 35 /bin/sh starts directly parented by Apache workers across three targets.[13] The targets were disposable phpot honeypots presenting ordinary PHP-backed pages.[13]
The reviewed targets ran PHP 8.4.26 under single-worker Apache mod_php with a 128 MiB memory limit.[13] The traffic closely matches the public HTTP-only proof-of-concept family, but the packet evidence does not identify the exact client or revision used.[13]
Scope matters: the report says this demonstrates the chain on an intentionally favorable single-worker mod_php profile, not reliability across other worker counts, PHP builds or applications.[13] Unit 42 separately says it cannot confirm that the PHP2Shell CVEs provided initial access in the European-government case it had previously described.[11]
Affected and fixed versions
| PHP branch | Affected upstream versions | First fixed upstream version |
|---|---|---|
| 8.5 | 8.5.0 through 8.5.11 | 8.5.12[8] |
| 8.4 | 8.4.0 through 8.4.26 | 8.4.27[8] |
| 8.3 | 8.3.0 through 8.3.35 | 8.3.36[8] |
| 8.2 | 8.2.0 through 8.2.34 | 8.2.35[8] |
PHP says all installations serving web requests are in scope, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.[2] PHP 8.1 and older no longer receive updates from the PHP project; operators must obtain a verified vendor backport or migrate to a supported branch.[2]
Cisco product update
Cisco lists Expressway 15.5.21 and product-specific workarounds[9]
Cisco’s interim advisory, updated October 26, lists Ultra-Reliable Wireless Backhaul (URWB), Expressway Series, and Expressway Select Series as vulnerable to the PHP2Shell advisory.[9] Cisco’s public table does not map each product to one or both individual CVEs, so administrators should not infer a product-specific CVE mapping that Cisco has not published.[9] Cisco’s public table does not enumerate the vulnerable release range for either Expressway product line.[9]
| Cisco product | Cisco bug | Listed fixed release | Important condition |
|---|---|---|---|
| Ultra-Reliable Wireless Backhaul (URWB) | CSCwx37073 |
27.1.1 (estimated February 2027)[9] | Cisco says exploitation requires an authenticated administrator; the product-specific CVSS score is 6.6.[9] |
| Expressway Series | CSCwx37062 |
15.5.21 (available)[9] | No separate product-specific prerequisite is stated in the public table.[9] |
| Expressway Select Series | CSCwx37062 |
15.5.21 (available)[9] | No separate product-specific prerequisite is stated in the public table.[9] |
Cisco lists product-specific workarounds for URWB and both Expressway product lines. Its future availability dates remain estimates subject to change, and it directs customers to the associated Cisco bugs for exact details.[9] Practical guidance: inventory exact product releases, evaluate the vendor-listed 15.5.21 release under normal compatibility and maintenance controls, use only Cisco’s product-specific workaround when an immediate update is not possible, and recheck the interim advisory before maintenance.[9]
Cisco PSIRT says it is not aware of malicious use of the vulnerabilities described in its advisory.[9] That Cisco-specific statement does not contradict the broader PHP exploit-attempt evidence above, and it is not proof that an affected Cisco deployment is either compromised or safe.[1][9][9]
New CISA detection resource
CISA adds a PHP2Shell SIGMA hunting rule[6]
CISA revised its PHP2Shell alert on October 23 to add a SIGMA rule for potentially suspicious activity, partner resources and reinforced mitigation guidance.[6]
The CISA-managed rule is titled “Detects PHP2Shell CVE-2026-109618 CVE-2026-109619 RCE Exploitation Attempts,” is marked status: test, and looks for combinations of HTTP request patterns, public-exploit markers, PHP error messages, and reported infrastructure or indicators.[10]
Treat it as a review-and-tune hunting aid, not proof of compromise. CISA’s rule file warns that some branches have a medium-high false-positive rate, that analysts may need to tune the query, and that the AND/OR conditions can use more memory and run longer than conventional SIGMA queries.[10]
Practical SMB response
Do these steps now
- Preserve evidence and review activity back to at least October 17. AWS recommends examining web-server logs, looking for suspicious POST activity, and checking for unexpected process execution or file modification on web application servers.[1]
- If you cannot patch an exposed system promptly, reduce exposure or take it offline. CISA advises organizations unable to update immediately—including those on unsupported PHP 8.1 or earlier—to take PHP-based systems offline until they can be patched or updated.[6]
- Find every internet-facing PHP runtime, not just the website or WordPress version. A plugin update does not repair these PHP-runtime flaws. If hosting is managed, ask the provider for the running PHP version, package build and completion time for the security update.[3]
- Move to a fixed build through your operating-system or hosting vendor’s supported update path. Confirm the active runtime reports the fixed release or a verified vendor backport; do not rely only on a control-panel selection or package download.[2]
- Keep WAF protections enabled while patching, but do not treat them as a complete fix. PHP says updating is the only safe choice, and AWS says there is no configuration-only workaround that fully addresses both issues.[2][1]
Why the Moodle US outage matters—and what it does not prove[7]
Moodle US reported that it proactively took hosted sites offline while applying and verifying PHP security patches.[7] In the October 22 snapshot preserved for this article, the incident remained in monitoring; the status page listed three named hosting/control-panel components in major outage and other listed services as operational. Moodle US said it had no clear timeframe for all patching to finish.[7]
This is evidence of operational disruption and a precautionary patching response, not evidence that Moodle software was exploited or that Moodle US customer systems were compromised.[7] Self-hosted Moodle operators should focus on the PHP runtime beneath their site and their own hosting provider’s patch status.[2]
Known limits
What remains unknown
- The successful execution evidence comes from three controlled honeypot targets; this article does not treat that controlled cohort as a production-victim count.[13]
- Honeypot and WAF observations prove exploit traffic was sent; they do not establish that every attempt succeeded.[1][3]
- CISA’s alert says CISA had not observed successful exploitation “as of the time of publication.” The later honeypot report documents successful execution on controlled targets, while Unit 42’s correction leaves the European-government initial-access path unconfirmed.[6][13][11]
- A dashboard label alone is not the version check: verify the active PHP package/build against a fixed release or a verified vendor backport.[2]
Bottom line
This is now confirmed execution on controlled targets, not a production-breach finding.[13] PHP says users should update immediately to fixed releases.[2] The honeypot report documents Apache-parented shell starts on its controlled targets.[13][2][13]
For Florida small businesses that outsource hosting, the fastest useful question is specific: Which fixed PHP build is serving our site right now, and when was the security update applied?[2]
Sources
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog, October 21, 2026.
- Security advisory: Critical remote code execution vulnerabilities, update now, PHP Group, October 21, 2026.
- Cloudflare deploys protections against php2shell vulnerability, Cloudflare, October 21, 2026.
- CVE-2026-109618: RCE via OOM corruption, CVE Program / PHP Group.
- CVE-2026-109619: RCE via stale global state, CVE Program / PHP Group.
- Critical Vulnerabilities in PHP Require Immediate Patching, CISA, October 21, 2026.
- PHP vulnerability incident, Moodle US Status, historical snapshot captured October 22, 2026.
- PHP web runtimes (CVE-2026-109618 and CVE-2026-109619), AWS Security Bulletin.
- Vulnerabilities in PHP Affecting Cisco Products: October 2026, Cisco Security Advisory, version 1.7, updated October 26, 2026.
- CISA SIGMA rule: PHP2Shell exploitation attempts, CISA-managed SIGMA Rules repository, modified October 23, 2026.
- Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619, Palo Alto Networks Unit 42; live correction retrieved October 26, 2026.
- PHP2Shell confirmed RCE: packet-to-process evidence from controlled honeypots, 0x4D31 honeypot-data report, October 24, 2026; retrieved October 26, 2026.
- Impact of Critical Vulnerabilities in PHP on Palo Alto Networks Products, Palo Alto Networks Security Advisory, live JSON retrieved October 25, 2026 at 20:48:25 UTC.