php2shell: How the Underground Is Responding to the Leaked PHP RCE Vulnerabilities

Executive Summary

On October 20, 2026, the PHP project issued an unscheduled notice of an upcoming critical security release after technical details of two previously undisclosed vulnerabilities leaked ahead of their planned, coordinated disclosure. The two flaws - tracked as CVE-2026-109618 and CVE-2026-109619, each rated 9.2 (Critical) under CVSS v4.0 and collectively nicknamed “php2shell” - are memory-safety defects in PHP’s request-handling path that, according to the PHP security team, allow unauthenticated remote code execution (RCE). Emergency fixes were released on October 21, 2026, at 14:00 UTC.

The leak triggered an unusually large and fast reaction across the cybercrime ecosystem. Within hours, KELA observed sustained discussion of php2shell on the Russian-language forums Exploit.in and XSS (where the news was reposted), on English-language forums and marketplaces (Cracked, BreachForums, T1erOne), on paste sites, and across more than 25 cybercrime and hacktivist Telegram channels and groups - roughly 150 forum, paste and social media posts and over 110 Telegram messages in the first two days. Activity has so far centered on three themes: the circulation and attempted reconstruction of proof-of-concept (PoC) code, open solicitation of a working exploit, and - in a smaller number of cases - overt attempts to sell or monetize access to an alleged “working” exploit.

KELA’s central assessment is that underground chatter is running ahead of what most cybercriminals in KELA’s sources can do on their own, but that gap is closing quickly. In the underground, KELA has not identified a vetted offer of access obtained through php2shell, several of the most experienced actors in the discussion remain skeptical that a stable, version-agnostic exploit exists, and many circulating PoCs are unreliable by their own authors’ admission. Outside the underground, however, reliable pre-authentication RCE has been demonstrated publicly: the PHP security team describes a working exploit against Apache mod_php in default configuration, and the research firm Calif has published a full technical write-up confirming unauthenticated RCE against 11 widely used PHP applications. Exploitation attempts are already widespread: Amazon recorded an attempt against its honeypots on October 17, four days before disclosure, and now describes php2shell as broadly exploited in the wild; Cloudflare’s CEO reported millions of attempts. What remains unconfirmed is success: as of October 22, no compromised victim has been publicly reported, and CISA has not added either CVE to its Known Exploited Vulnerabilities (KEV) catalog. Organizations should treat exploitation as active and patch immediately. This blog summarizes KELA’s underground findings, indicators and recommended actions – this is current as of October 22, 2026, 13:00 UTC.

The php2shell Disclosure

PHP is one of the most widely deployed server-side languages on the internet, which makes any pre-authentication RCE in its core request path a high-impact event. According to the PHP security team’s advisory, the two vulnerabilities are memory-safety defects - described as memory corruption during out-of-memory handling and the reuse of internal state after memory has been freed - reachable through specially crafted web requests. The flaws affect common deployment models including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, with Apache mod_php cited as presenting the highest exploitation risk. Fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no official release, although the PHP security team published minimal source backports for PHP 7.4, 8.0 and 8.1 and some Linux distributions and LTS vendors provide backported packages; the vulnerable code dates back to PHP 5.4.0, and branches older than 7.4 have no fix at all.

The event is notable as much for how it became public as for its technical severity. Public reporting indicates the issue first surfaced through an anonymous online post that offered no corroborating evidence, was subsequently amplified by independent researchers, and was then substantiated by a security vendor that named the two CVE identifiers before the embargo was due to lift. This forced the PHP project to accelerate its release schedule. The bugs were discovered by Calif, Wiz Research and OpenAI and reported to PHP in August 2026; the “php2shell” name comes from Calif’s research and exploit tooling. The leak was tracked publicly by researchers and threat-intelligence channels - including Kevin Beaumont, watchTowr, and Huntress - whose commentary shaped how the underground first understood the issue.

The root cause is now confirmed by the PHP advisories and the researchers’ write-ups. CVE-2026-109618 is triggered when a crafted multipart request exhausts PHP’s memory limit mid-parsing, leaving request data half-initialized. CVE-2026-109619 is a use-after-free of request state left behind after a fatal error, reachable among other paths through session.upload_progress, which a later request handled by the same worker can consume. The pre-patch underground PoCs folded both bugs into a single session.upload_progress chain, so their labels do not always match the CVE they actually exercise.

Vulnerability Summary

The following summarizes the key parameters of the php2shell vulnerabilities, per the PHP project’s advisory and associated public reporting.

Underground Response Observed by KELA

Proof-of-Concept Circulation on Exploit.in

The most technically substantive underground discussion appeared on the Russian-language forum Exploit.in, where a dedicated thread titled “PHP2Shell (CVE-2026-109618 и CVE-2026-109619) - У кого-нибудь есть?” (“Does anyone have it?”) drew dozens of replies within the first day. A separate thread, “POC PHP CVE-2026-109618 CVE-2026-109619,” posted on October 21 by the user Mr.Wizard, carried the fullest PoC KELA observed on the forum: paired scripts targeting each CVE, implementing a session.upload_progress use-after-free intended to redirect execution into an internal PHP function, together with code to fingerprint the target’s server interface (including LiteSpeed/lsphp) and a hard-coded memory offset for a specific Ubuntu PHP build. The same code also circulated on Pastebin. The posted code is attributed to the lineage of a publicly circulated PoC hosted on the domain jackalsyn[.]com (actor handle “J4ck3LSyN”).

Two public code repositories were referenced repeatedly as PoC sources: github[.]com/ikow/php2shell-poc, shared several times on Exploit.in and Telegram, and github[.]com/wakemeiflose/php2shell, referenced on Telegram. At least one forum member noted that the former predates the patch and may not reflect the final vulnerabilities.

An important reservation is that KELA has not independently validated any of these PoCs. Forum participants themselves reported that publicly posted versions frequently “need rework,” and the J4ck3LSyN PoC lineage was publicly updated to acknowledge that the attack chain it originally described did not function. KELA therefore treats all circulating php2shell PoCs as unverified and, on current evidence, of limited and inconsistent reliability.

Community Skepticism Over Real-World Exploitability

A recurring and analytically important theme is that several experienced Exploit.in members openly doubted that a dependable exploit existed. The core technical objection raised across multiple posts is that the use-after-free requires memory offsets that differ by PHP version and architecture and cannot be reliably brute-forced, meaning a working exploit would have to be tailored per target build. Representative positions included assessments that the bug is “not exploitable” because the offsets cannot be enumerated, that a separate RCE routine “must be written for each PHP version,” and that even reworked public PoCs would fail against the large majority of real targets. One participant argued the flaw is realistically exploitable only in narrow insider scenarios (for example, a former administrator who already knows the target’s exact build).

A minority of participants claimed the opposite - that a working RCE was “ready” and that scanning and tooling were already in development - and at least one solicited partners to monetize a “PoC + RCE chain.” KELA cannot verify these claims and notes they are unsubstantiated.

Ultimately, KELA finds that most expert sources favor a skeptical position: a universally reliable, drop-in php2shell exploit does not appear to be in broad circulation in the underground at the time of writing. However, this objection is weakening: the published research shows the same bugs can leak worker memory, which can supply the addresses an exploit needs, and a Telegram channel monitored by KELA is already circulating a tool that claims to bypass ASLR without per-target changes. This should not be read as an all-clear - targeted, build-specific exploitation by capable actors remains plausible, and the barrier is expected to fall further now that the patch and full technical write-ups are public.

Exploitation Claims and Monetization Attempts

On the English-language marketplace Cracked, KELA found a user operating as “Gopnik” published a thread advertising a purported “0DAY PHP2SHELL EXPLOIT” with claims of universal website compromise, hidden content hosted on a third-party paste service, and operational prompts to “start breaching now” and to enumerate origin IP addresses where a web application firewall (notably Cloudflare) blocks the request. The same actor promoted paid “mentorship” via a Telegram bot; a separate user replying in the thread advertised an unrelated data-leak shop.

A clear reservation attaches to this activity: the presentation, audience and bundling of this listing are consistent with low-tier, opportunistic marketing aimed at inexperienced buyers, and KELA has not verified that any functional exploit was actually provided. Separately, a WordPress exploit by the research firm Calif, first seen in a briefly posted video, has since been confirmed in Calif’s published write-up, which reports unauthenticated RCE against WordPress and ten other PHP applications. KELA did not identify any vetted listing offering verified server access obtained specifically via php2shell.

Paste-Site Artifacts and Target-Specific Adaptations

KELA observed a large and still-growing set of php2shell artifacts on paste sites. These span three categories: (1) exploitation attempts (multiple PoC variants, including a use-after-free chain, a session-file-injection chain and a deserialization/handler-mismatch chain); (2) target-specific adaptations, most notably a PoC rewritten to target a specific MediaWiki deployment running an older PHP release; and (3) a substantial body of defensive material, including detection signatures, compromise-check scripts and mitigation scripts for various operating systems and container setups. KELA also observed prompts instructing AI assistants to “research” and weaponize the vulnerability.

The coexistence of attack and defense artifacts, and the prevalence of adaptation and tooling attempts over confirmed successes, is consistent with a community actively working on the problem rather than one already in possession of a turnkey capability.

Demand Across Cybercrime Telegram Communities

Demand was especially visible on cybercrime-oriented Telegram. Most of the over 110 php2shell messages KELA recorded on Telegram were news reposts and links to checker tools; actual actor discussion was concentrated in Nxploited, an exploit-sharing Telegram group with about 3,000 members, where KELA recorded 22 relevant messages on October 20–21. Members repeatedly requested a PoC, debated the credibility of leaked details, exchanged the two public GitHub repositories noted above, and asked for scanning “dorks” and automated checkers to enumerate vulnerable hosts at scale. One member said they had tested a posted repository in a lab, and another posted an unsupported claim of a “ready” exploit, while more measured voices told the group to wait for the official patch and compare it with the previous version before attempting analysis.

These messages should be read with caution. Most participants appear to be low-skilled actors looking for ready-made tools rather than building them; the claims of a working exploit came with no code or evidence; and the discussion carried clear misinformation, including an unrelated CVE mixed into the thread and a claim that one of the two bugs is rated 9.8 or 10 (both are rated 9.2). A claim that there was “evidence someone exploited it successfully” was not substantiated. The pattern - high-volume requests for ready-made tooling, combined with few credible claims of success - mirrors the dynamic seen on the forums.

Hacktivist channels, including Malaysia Hacktivist and Tengkorak Cyber Crew, mainly relayed news coverage and checker tools rather than claiming attacks. On October 22, a Telegram channel monitored by KELA shared “php2shell-bypass-aslr-exp,” a tool its poster claims works against unmodified PHP builds without the memory-limit or display_errors preconditions; KELA has not validated it.

Scanning and Targeting Indicators

The public PoC KELA observed on Exploit.in, and its Pastebin copies, embed distinctive, hard-coded request characteristics. Opportunistic scanning that reuses this PoC is already visible in the wild: a researcher posted these exact User-Agent strings and boundaries from server logs early on October 21, and security vendors recorded requests carrying them from the same morning, before the patch was published. These requests are identifiable by the fingerprints listed in the indicators table below - in particular the self-identifying User-Agent strings, the fixed multipart boundaries, and anomalous multipart/form-data POST requests carrying the PHP_SESSION_UPLOAD_PROGRESS field directed at endpoints that do not legitimately handle uploads. Since the advisory was published, vendors have also seen tooling that follows the documented CVE-2026-109618 out-of-memory technique, which does not use that field.

KELA also observed low-credibility claims in open board discussion asserting long-running prior exploitation of the underlying flaw; these are uncorroborated and are assessed as noise. More broadly, a wave of precautionary service shutdowns across both legitimate and underground sites - undertaken ahead of the patch - is itself an indirect indicator of how seriously the ecosystem treated the disclosure. Several Dutch sites, including Tweakers, the House of Representatives, NCSC-NL and Security.NL, went offline on October 21, and national CERTs including the UK NCSC and CERT Polska advised organizations to consider taking unpatched PHP services offline. Underground platforms did the same: the forum PwnForums went down for what a Telegram channel described as “PHP bug maintenance,” and a post on a Japanese-language onion board attributed outages of the darknet forum Dread and of Kiwi Farms to the wait for the PHP patch.

Assessment

"The underground is loud about php2shell, but loud is not the same as capable. What we are watching for is the shift from requests for a working exploit to reputable actors selling access gained through it. When that happens, the window to patch has already closed." Elad Ezrahi, Head of the KELA Cyber Intelligence Center.

Following are KELA’s key assessments:

• The disclosure is genuine and high-impact. KELA assesses with high confidence that two critical, pre-authentication RCE vulnerabilities in PHP’s core request path, affecting mainstream deployment models, warrant urgent patching regardless of the current state of public exploitation.
• Underground capability lags the public research, but not for long. It appears that most cybercriminals in KELA’s sources do not yet have a reliable exploit, and several circulating PoCs are unreliable by their own authors’ admission; however, reliable pre-authentication RCE has been demonstrated publicly by the PHP security team and by Calif, and the remaining technical barrier (target-specific memory offsets) can be overcome with the memory-disclosure behavior of the same bugs.
• Exploitation attempts are widespread, but no compromise has been confirmed. KELA assesses with high confidence that php2shell is being exploited at scale in the wild, with attempts recorded from October 17, before disclosure, and running into the millions after the patch; vendors have observed tooling that follows the documented techniques, scanners that attempt to install a botnet loader, and existing multi-exploit bots adding php2shell. KELA assesses with moderate confidence that no successful compromise attributable to these CVEs has yet been established in its sources or in public reporting; this judgment is time-sensitive and likely to change.Monetization attempts are present but largely low-credibility. KELA assesses with moderate confidence that the observed “for sale” activity is consistent with opportunistic marketing to inexperienced buyers, having found no vetted access listings tied to these CVEs.
• Risk is expected to increase. KELA assesses with moderate confidence that the barrier to reliable exploitation is likely to fall as the released patch and the researchers’ write-ups are analyzed and offset-handling is generalized. Organizations should therefore act on patch urgency now rather than on the current, still-immature underground exploitation landscape.

Recommendations

• Patch as the priority control. Upgrade all PHP instances to a fixed release (8.5.12, 8.4.27, 8.3.36 or 8.2.35) and plan migration for any end-of-life branch (PHP 8.1 and older receive no official release; minimal source backports exist for 7.4, 8.0 and 8.1). After updating, restart Apache or PHP-FPM, and rebuild and redeploy container images with the patched runtime. Prioritize internet-facing hosts and inventory PHP across applications, containers and third-party software.
• Treat interim mitigations as partial. PHP states that only an update is a complete fix. For CVE-2026-109619, set session.upload_progress.enabled=0 (and, on PHP 8.5, fatal_error_backtraces=0) in php.ini or the FPM pool - not in .user.ini or via ini_set() - and restart every worker. For CVE-2026-109618, set memory_limit=-1 in a way applications cannot override, lower post_max_size (8M without uploads, 32M with), and cap request size, multipart part count and header count at the web server or proxy, including requests without a Content-Length. Where uploads are not needed, block multipart/form-data. These steps reduce exposure but do not make a server safe.
• Hunt for the PoC-derived fingerprints in the indicators table below, with the caveat that these signatures reflect the current public PoC and can be trivially changed by a capable actor; absence of these indicators is not evidence of safety.
• Hunt for compromise, not only for scanning. Review web server and PHP logs from October 17 onward (the earliest exploitation attempt reported) for unusually large or deeply nested multipart requests and multipart requests without a Content-Length; alert on PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells, interpreters or download tools; and check web roots for new PHP files, plus new cron jobs and accounts. Include third-party products that bundle PHP. Isolate and preserve logs from any host with suspicious findings.
• Validate WAF/origin exposure. Actors have explicitly discussed bypassing WAFs by locating origin IP addresses; ensure origins are not directly reachable and that protection is not solely perimeter-based.
• Monitor the underground for signs that the threat is maturing or reaching your organization. Track the signals that would mark a shift from chatter to action: a generalized, offset-independent exploit (watch the jackalsyn[.]com / J4ck3LSyN PoC lineage and the referenced public repositories), working exploits offered by reputable actors on vetted forums, initial access brokers listing web-server or shell access obtained through php2shell, and ransomware or data-extortion groups adopting it. Watch also for your own domains, IP ranges and web applications appearing in shared target lists, scanner output, access listings or leak posts, and for credentials or data taken from your web servers.

Selected Indicators and References

The detection fingerprints below are derived from the public PoC observed by KELA on Exploit.in and in Pastebin copies of it, from attack traffic reported by security vendors since October 21, and from actor-referenced infrastructure. They are provided for monitoring and triage, all are low-cost for a threat actor to change and should be used as leads rather than definitive signatures. Domains, URLs and IP addresses are defanged.

From Chatter to Action: Closing the php2shell Gap

php2shell shows why a CVSS score alone cannot drive patching decisions. Security teams need to know three things: how likely a vulnerability is to be exploited, which of their internet-facing assets are exposed, and whether the vendors they rely on are exposed too.

Vulnerability Intelligence: Look up CVE-2026-109618 and CVE-2026-109619 to see CVSS severity, EPSS exploitation likelihood, exploitation status (from PoC Available to Active Exploitation), remediation steps and a timeline of how each CVE's risk has changed since disclosure. The Intelligence Feed shows the underground posts that reference each CVE, so analysts can read the threads where actors discuss, sell or share exploit code instead of inferring intent from a score.

External attack surface: KELA flags potential vulnerabilities on your internet-facing digital assets, including sensitive open ports, vulnerable software and web applications, and maps exposed hosts so unpatched servers surface for remediation.

Vendor risk: php2shell also reaches third-party products that bundle PHP. KELA Third-Party Risk Management maps vendors' external infrastructure from the outside in and enriches each vendor's risk profile with vulnerability, exposed-credential, ransomware and dark web intelligence, so you can prioritize the suppliers that need to patch first.

The key takeaway: the gap between underground chatter and working exploits is closing, and the time to patch is before it does.