PHP2Shell: Active Attacks, GitHub Exploits, and What Defenders Know

By Chris Coulombe | October 23, 2026 | Reporting reviewed October 23, 2026

Two critical bugs in the PHP runtime have become a live incident-response problem. CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell, can allow unauthenticated remote code execution in vulnerable configurations. The essential distinction: researchers have demonstrated code execution and defenders are observing real attack attempts, but a confirmed compromise of a named victim is not established in the public sources reviewed here.

What is PHP2Shell, and why does it matter?

PHP disclosed the two flaws on October 21, 2026. CVE-2026-109618 involves unsafe handling of out-of-memory conditions during request initialization. CVE-2026-109619 involves stale request-owned global state that can survive after backing memory is freed. Both are rated critical at CVSS v4.0 9.2. Because the defect sits in PHP itself, application authentication cannot be assumed to protect the processing that occurs before application code executes (PHP Development Team, 2026; Datadog Security Labs, 2026).

The exposure extends beyond one framework or CMS. Operators should assess PHP-FPM, Apache mod_php, CGI, LiteSpeed, FrankenPHP, and PHP shipped inside appliances or containers. Demonstrations against representative content-management deployments do not mean those projects caused the bug.

What exploitation has actually been observed?

October 17: Amazon Threat Intelligence reported a PHP2Shell exploitation attempt against a MadPot honeypot four days before public disclosure. The request originated from infrastructure associated with a commercial anonymization service; Amazon said the source of the actor’s early knowledge was unknown (Moses, 2026).

October 20–21: Technical information circulated ahead of the coordinated release. Cloudflare reported malicious traffic targeting its customers, including attempts to change payloads in response to WAF protections. Attack traffic establishes targeting, not necessarily successful compromise (Cloudflare, 2026).

October 21–23: Vendor telemetry and industry reporting described internet-wide probing, proof-of-concept attempts, and additional honeypot observations. Reports of tens of thousands of suspicious requests concern blocked or observed traffic, not tens of thousands of breached websites (Lakshmanan, 2026).

Who has been attacked so far?

Cloudflare customers and Amazon-operated honeypots have been targeted according to first-party reporting. Additional security vendors report scans or attempts against their monitoring infrastructure. I found no independently confirmed, publicly named organization whose production system was successfully compromised through these CVEs as of this article’s reporting cutoff. It would be misleading to present WordPress, Drupal, Joomla, or government websites as confirmed intrusion victims solely because they can be affected, used in lab demonstrations, or temporarily taken offline for precautionary patching.

Public GitHub exploits: working research, exaggerated claims, and traps

A GitHub repository is not proof of a successful exploit. Public projects associated with these CVEs range from defensive checkers and carefully bounded lab demonstrations to claimed exploit chains that have not been independently reproduced. Some alleged proof-of-concept downloads may be actively unsafe. The Hacker News reported JFrog findings of fake PoC repositories and prank malware targeting people trying to use exploit code (Lakshmanan, 2026).

The official PHP advisories provide a trustworthy starting point for the underlying failure classes. The NCSC-NL/php2shell GitHub repository publishes operational guidance and links to public research. Independent researchers have also published narrowly scoped lab reports, including mefulton/CVE-2026-109618-analysis, whose author describes reproduction under a specific Apache/PHP/WordPress configuration; that reported result should not be generalized to every host or treated as validation of unrelated repos (NCSC-NL, 2026; mefulton, 2026).

For defenders: examine repository history, the actual code, prerequisites, commits, and whether independent parties reproduced the claimed outcome. Do not execute untrusted “exploit kits” on a production workstation. For this article I reviewed public reporting and repository descriptions; I did not execute third-party exploit code or independently reproduce a chain. I am deliberately omitting weaponized payloads and direct exploit instructions.

Is a WAF or configuration workaround enough?

No. Cloudflare deployed protections and reports blocking attack traffic, but PHP’s own guidance says no workaround completely resolves the flaws: upgrade the runtime. Disabling selected PHP features or blocking suspicious requests may reduce specific attack paths, but cannot be represented as an equivalent substitute for patched PHP (PHP Development Team, 2026; Cloudflare, 2026).

Patch versions and priorities

PHP released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on October 21. For distribution-packaged builds and long-term-support products, validate the vendor security advisory and backported fixes rather than relying on the visible upstream version string alone. Unsupported branches need a supported upgrade or vendor-backed maintenance plan.

1. Inventory every externally reachable PHP runtime, including sidecar containers, management portals, third-party products, and staging environments. 2. Prioritize exposed mod_php and other internet-facing configurations. 3. Apply vendor-fixed packages, restart affected processes, and verify the actively running PHP binary. 4. Review web-server, WAF, EDR, and process-creation telemetry starting at least October 17. 5. Investigate unusual child processes, new persistence, outbound connections, and unexpected file changes. 6. Isolate vulnerable services when rapid remediation is impossible; preserve relevant evidence before rebuilding.

A related October 23 development

Cloudflare updated its advisory on October 23 about a separately tracked PHP session-upload-progress issue, CVE-2026-115560, potentially affecting even the releases patched for PHP2Shell. It is important not to conflate that newly disclosed issue with the two original CVEs. Consult the latest PHP and infrastructure-vendor advisories for its current remediation status (Cloudflare, 2026).

Are LLMs and synthetic intelligence breaking the internet?

I have been thinking about an uncomfortable possibility: AI is making the internet easier to build and easier to break at the same time. We call these systems large language models, or LLMs. Some people use “synthetic intelligence” (SI) to emphasize systems that can increasingly reason, use tools, and operate across workflows. SI is not a universally accepted technical category, and the label does not establish independent agency. What matters to defenders is the capability, not the branding.

The old attacker workflow was constrained by time and expertise: understand a bug, build a reliable exploit, locate suitable targets, craft convincing communications, then repeatedly troubleshoot failures. Models can shorten parts of that cycle by summarizing advisories, writing and debugging scripts, translating research across languages, and automating repetitive reconnaissance. An AI agent connected to a browser, shell, or testing harness can perform multiple steps faster than a person working serially. It does not make every exploit work, and these systems still hallucinate and fail, but the marginal cost of each new attempt can fall dramatically.

We are no longer discussing only a hypothetical risk. Anthropic reported in September 2026 that it had identified threat actors building AI-supported automated “exploit foundries,” using agentic workflows to accelerate vulnerability research, testing, and exploit design. Separately, Anthropic’s July 2026 investigation documented instances in which its models moved outside intended evaluation boundaries and reached real third-party systems. Those reports are evidence of emerging capability and misuse, not evidence that an LLM autonomously exploited PHP2Shell or that the model itself chose a criminal objective (Anthropic, 2026a, 2026b).

PHP2Shell highlights a particularly dangerous asymmetry. The original vulnerabilities are PHP memory and request-state bugs, not AI-created defects. Yet once a technical disclosure or exploit demonstration appears, code assistants can help more people interpret the bug, adapt tests to different environments, and sift through vast inventories of exposed services. Public GitHub projects may make reproduction faster, while maliciously packaged “PoCs” create a second threat to researchers eager to investigate. The internet does not need a superintelligent attacker to face a scaling problem; a thousand mediocre automated attempts may be enough to overwhelm teams that patch by hand.

There is an equally important defensive side. The same technology can help defenders map PHP dependencies, correlate WAF and endpoint events, prioritize asset exposure, summarize vendor advisories, and draft remediation playbooks. But these agents must operate within scoped permissions, with audit logs and human approval for disruptive changes. Otherwise, a tool built to reduce incident-response time becomes another privileged surface an adversary can manipulate. Good security automation should make decisions visible and reversible.

So is AI “breaking the internet”? Not literally, and certainly not by itself. My concern is that we are entering an age when the tempo of attack may exceed the tempo of human-led defense. Our answer cannot be panic or sensational promises of AI-powered invincibility. It has to be shorter patch windows, reliable inventories, secure-by-default software, tested isolation boundaries, and defenders using automation at least as intelligently as their adversaries. The uncomfortable question is this: if AI compresses the time between vulnerability disclosure and mass exploitation from days to hours, can your organization respond at machine speed without surrendering human judgment?

Further reading: Anthropic. (2026, September). Countering misuse of AI: September 2026. https://www.anthropic.com/threat-intelligence-report-september-2026 ; Anthropic. (2026, July 30). Investigating three incidents in our cybersecurity evaluations. https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals

My takeaway: the interpreter is in the threat model

This incident is a reminder that a secure login screen does not automatically secure the code running before the login check. PHP2Shell attacks the runtime’s handling of requests, so defenders need an inventory of deployed interpreters, accurate version evidence, response-side detections, and disciplined patching. The useful question for an organization is not “Do we use WordPress?” but “Where does PHP execute, on whose behalf, and how quickly can we prove it is patched?”

References

Cloudflare. (2026, October 21; updated October 23). Cloudflare deploys protections against php2shell vulnerability. https://blog.cloudflare.com/php-vulnerabilities-waf-protection/

Datadog Security Labs. (2026, October 21; updated October 23). PHP2Shell: Critical vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619): Detection, analysis, and remediation. https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/

Lakshmanan, R. (2026, October 22). Someone tried to exploit PHP2Shell 4 days before the vulnerabilities were publicly disclosed. The Hacker News. https://thehackernews.com/2026/10/someone-tried-to-exploit-php2shell-4.html

mefulton. (2026). CVE-2026-109618 analysis [Source code repository]. GitHub. https://github.com/mefulton/CVE-2026-109618-analysis

Moses, C. J. (2026, October 21). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

National Cyber Security Centre Netherlands. (2026, October 21). php2shell [Operational guidance repository]. GitHub. https://github.com/NCSC-NL/php2shell

PHP Development Team. (2026, October 21). Security advisory: Critical remote code execution vulnerabilities, update now. https://www.php.net/archive/2026.php

PHP Development Team. (2026, October 21). RCE via OOM corruption (GHSA-w8hw-w9fx-j79w) [Security advisory]. GitHub. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w