PHP2Shell Exposure Falls 67%: An ItInsightsWorld Security Checklist for Remediation, IOCs, and Failed Exploitation Trends

ItInsightsWorld Security reads the PHP2Shell coverage through a remediation lens: Last week, a disclosure described two major vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, and the follow-on signal now matters more than the label of the exploit. According to the Wiz Research team, publicly available code has been reviewed, telemetry shows limited exploitation attempts, and no public proof of concept (PoC) demonstrates complete, general end-to-end exploitation against an arbitrary target; some partners have privately disclosed exploits that work against a variety of targets, internal experimentation continues, and videos demonstrating successful exploitations are available at php2shell.com.

This article converts the same real-world exposure, honeypot, and failed-attempt evidence into a narrower operational question for security teams: which PHP2Shell risk has actually fallen, which attack mechanics keep failing, and what should be verified next?

Where exposure has fallen—and where uncertainty remains

Wiz telemetry shows that, following PHP2Shell's public disclosure on October 21, 2026, the daily number of distinct Internet-exposed machines vulnerable to PHP2Shell dropped by approximately 67% over the past few days. Among vulnerable Internet-exposed machines, the share running PHP version 7.3 or earlier fell from 8.3% to 5.7% over a period of five days. This measures the portion of the observed population running older versions that did not receive official backports.

During the same period, the number of significantly affected organizations, defined as those with at least one exposed and vulnerable instance, fell by approximately 47.9%. For reference, PHP itself is in use by 65% of organizations in the dataset.

The pattern is consistent with organizations reducing exposure through patching, upgrading, retiring affected machines, and restricting internet access. The data shows the overall trend but does not establish the relative contribution of each remediation strategy; scan coverage and population size can also affect reported numbers over time. One week after public disclosure, less than 53% of initially affected organizations remained vulnerable to PHP2Shell.

Attack mechanics observed: two variants, partial progress, and failed final stages

The observed activity falls into two broad types. First, attempts using the PHP2Shell exploit mechanism with techniques matching those of public PoCs. Second, PHP2Shell-branded tools unrelated to the vulnerabilities that instead relied on session poisoning and a separate local file inclusion (LFI) vulnerability in the application.

The Wiz Research team observed two variants of an open source exploit kit targeting PHP-based software. Neither completed the exploit chain in captured attempts. The older variant encountered request-size limits or failed to produce the expected memory-exhaustion condition. The newer variant consistently exhausted PHP memory but failed to obtain the memory addresses needed to continue.

Legacy chain attempt from 3.37.227[.]134

The first request to the PHP-CGI honeypot came from 3.37.227[.]134. It matched the kit’s older chain, found under archive/legacy-8m/exploit.py and its accompanying stage scripts. The first full exploit stage used a multipart body containing 1,005 parts, including a field named big filled with approximately 12 MB of padding.

According to the kit’s notes, this stage attempts to exhaust memory during a session reset, leaving the session state available for a later request. On the honeypot, it failed before reaching that code. The declared POST content-length of 12655437 bytes exceeded the configured 8 MB post_max_size limit of 8388608 bytes, so PHP skipped processing the multipart body.

The author has since moved this chain into the kit’s archive directory.

Roundcube heap-shaping attempt

In a later attempt, 103.151.172[.]95 sent a longer sequence from the legacy chain. It included stalled connections intended to occupy other Apache workers. When only one worker was available, the exploit attempted heap-shaping by sending requests containing 1,001 fields of 3,000 bytes each. These requests did not trigger the memory exhaustion flow required, so there is no evidence that this attempt reached the intended memory-exhaustion condition.

Current chain: more memory exhaustion, no leak

Most captured IP addresses used the newer chain, built from pure/mk_a1.py and pure/mk_leak_b.py. This variant was observed in multiple attempts and progressed further: its first stage consistently caused PHP to exhaust its memory. The following stage, which attempts to leak process memory, failed in every captured run. The server logged a fatal error indicating that PHP reached its limit, for example that the allowed memory size of 134217728 bytes was exhausted while trying to allocate 81920 bytes in Unknown on line 0.

Worker-pinning pressure and request padding

The chain depends on consecutive exploit requests reaching the same Apache child process. To increase the chances of that happening, the kit attempts to occupy the other workers with incomplete requests. Each connection declares a large body of 1048576 bytes, sends a single byte, and stalls. One address, 178.249.214[.]6, opened 399 of these connections alongside 400 GET requests before sending the exploit stages. The address is a VPN exit node, which limits what can be inferred about the source.

Stage A1: exhaustion achieved

A1 is a chunked multipart request containing a null-byte session ID, 860 empty file parts with long, deeply nested array names, and several groups of padding fields. The request totaled 1,060,211 bytes and 974 parts. It also included 14 f0000xxxx... fields, 78 b0000 fields of 8000 bytes, 20 u00 fields of 4000 bytes, and a PHP_SESSION_UPLOAD_PROGRESS field of 4000 bytes.

The request is designed to exhaust memory during session handling at a point that can leave the session ID pointing to freed memory. Every A1 request captured returned HTTP 500, accompanied by a PHP error indicating that the allowed memory size of 67108864 bytes was exhausted in Unknown on line 0.

This confirms that A1 reached the intended memory-exhaustion condition on the honeypot. It does not, by itself, confirm that the stale session state needed by the next stage was preserved.

Stage B1: attempted memory leak not observed

B1 followed roughly a second later. It sent another chunked multipart request containing PHPSESSID=a, PHP_SESSION_UPLOAD_PROGRESS=k0 and two large padding fields. If this request reaches the same worker before PHP resets the stale session state, PHP can write reclaimed heap contents into a PHPSESSID response cookie. The kit then extracts heap and libphp addresses from that cookie to prepare the final exploit stage.

No such leak was observed. In all but one run, the connection closed without a response. The remaining run returned a normal 32-character session cookie. None of the sources sent the final exploit stage.

Why the chain may fail in real deployments

The failed leaks highlight a broader challenge: building a generalized exploit that works reliably across PHP versions and deployment configurations is difficult. The kit’s B1 layout was calculated for the official php:8.4.26-apache image with a 128 MB memory limit. Other instances, such as the Roundcube honeypot, ran the same PHP version from a different build, with additional extensions and a 64 MB memory limit. These differences can affect heap layout and memory reuse, potentially preventing the leak from working as expected.

Reliable worker pinning adds another challenge. Consecutive exploit requests must reach the same Apache child process while the required session state persists. Request timeouts, network latency, and worker availability can disrupt this sequence. In internal testing, request timeouts combined with network latency were enough to prevent the chain from completing over an internet connection.

So far, no publicly available, generalized solution has been identified for either worker pinning or information leaking across different deployments. Simply copying public PoCs and running them at scale does not address the work needed to turn a configuration-specific exploit into a reliable operational kit. These barriers are expected to diminish over time: some threat actors have the expertise needed to adapt the chain and build more robust tooling.

Other attempts and the honeypot exploit evidence

Failed exploitation attempts were also seen from 15.204.59[.]70 and 162.35.99[.]94. These scanners did successfully exploit Adel Karimi's honeypot, which was a likely contributing factor to CISA’s decision to include PHP2Shell in the KEV list.

Branded tools that did not use the PHP2Shell vulnerabilities

Tools labeled as PHP2Shell exploits were also observed that did not attempt to exploit either vulnerability. The earliest such traffic, from 85.11.187[.]35, matched a Go port of “Chain A” from WoYinDao/CVE-2026-109618-CVSS-9.2-Critical.

The tool used a longstanding session-poisoning technique, attempting to write PHP code into a session file through the upload-progress feature. It then attempted to execute that code by including the session file.

Crucially, lfi_sink.php is a vulnerable endpoint supplied by the PoC’s lab environment. The tool assumes that this endpoint exists on the target; without it or an equivalent local file inclusion (LFI) vulnerability, the chain cannot execute code. A padded variant triggered the memory-exhaustion detection, but no successful code execution was observed. Despite the PHP2Shell branding, this activity relied on an unrelated technique and a vulnerable application endpoint.

ItInsightsWorld Security checklist for this PHP2Shell activity

• Confirm whether internet-facing machines are exposed to PHP2Shell, using the observed remediation paths from the master reporting: patching, upgrading, retiring affected machines, and restricting internet access.
• Identify PHP version and build details for vulnerable assets, especially PHP version 7.3 or earlier and PHP 8.4.26 deployments such as php:8.4.26-apache.
• Check PHP and Apache runtime constraints that were relevant to the failed exploit chain: post_max_size around 8 MB or 8388608 bytes, memory limits such as 128 MB and 64 MB, worker behavior, mod_php settings, and session-state lifetime.
• Review application endpoints that could act as an LFI sink, including lfi_sink.php-like patterns, because branded tools that did not use the vulnerabilities depended on such endpoints.
• Map the IOC table into blocking, hunting, and log correlation: scanner + exploitation attempt, exploitation attempt, VPN exit-node activity, and C2 (payload server) indicators.
• Do not treat the absence of a public generalized PoC as closure; continue monitoring because private disclosure, internal experimentation, videos at php2shell.com, and adaptation by capable threat actors remain part of the picture.

Common misconceptions in the PHP2Shell discussion

• That any traffic labeled PHP2Shell means the underlying PHP CVEs were exploited; the report includes PHP2Shell-branded tools unrelated to the vulnerabilities.
• That memory exhaustion equals successful end-to-end compromise; Stage A1 reached the intended memory-exhaustion condition, but B1 memory leak did not succeed in captured runs.
• That a public PoC is directly scalable; copying public PoCs and running them at scale does not address worker pinning, leak reliability, and deployment-specific changes.
• That declining exposure proves a single fix worked; the data shows trend but does not establish relative contribution of patching, upgrading, retiring, or internet-access restriction.

FAQ for security teams

Q: Has the Wiz Research team observed complete PHP2Shell exploitation in its own telemetry?

A: No. The team's own telemetry had not observed successful end-to-end PHP2Shell exploitation. Adel Karimi's public report and supporting data provide the most robust public evidence seen to date, correlating exploit traffic, memory disclosure, and subsequent code execution on his honeypots.

Q: Why do the Roundcube and official container differences matter?

A: Because exploit layout was calculated for official php:8.4.26-apache image with a 128 MB memory limit, while Roundcube honeypot used same PHP version from different build, additional extensions, and a 64 MB memory limit. These can affect heap layout and memory reuse.

Q: Does a normal session cookie rule out risk?

A: Not by itself. B1 normally expected to leak heap and libphp addresses via PHPSESSID cookie; in all but one run the connection closed without a response, and the remaining run returned a normal 32-character session cookie. None of the sources sent the final exploit stage.

Action recommendations

1. Apply PHP security updates or remediate through other means for exposed systems; the master report identifies patching, upgrading, retiring, and internet-access restriction as consistent exposure-reduction measures.
2. Prioritize internet-exposed PHP assets first, especially any instance that can receive multipart requests, uses session upload-progress features, or is served by Apache with mod_php.
3. Use IOCs for threat hunting, not blind blocking: include 85.11.187[.]35, 172.206.2[.]199, 3.37.227[.]134, 103.151.172[.]95, 178.249.214[.]6, 31.56.197[.]72, 135.136.19[.]197, 15.204.59[.]70, and 162.35.99[.]94 in searches, noting VPN and C2 labels.
4. Validate that application code does not rely on vulnerable endpoints such as lfi_sink.php-like local file inclusion sinks; without such endpoints, the branded Go-chain activity could not execute code in captured reporting.
5. Review PHP memory, post body, and session-reset behavior under realistic worker counts and latency, because worker pinning and request timeouts are repeatedly described as factors preventing complete chains.

Bottom line for ItInsightsWorld Security readers

From this site's Security perspective, the useful reading is that PHP2Shell remains a risk in both the short and long term while current public evidence does not show a broadly reliable end-to-end exploit in the team's own telemetry. The declining exposure metrics—67%, 8.3% to 5.7%, 47.9%, and 53%—are not reasons to stand down; they are reasons to verify the actual remediation path, because scan coverage, population size, PHP builds, memory limits, and Apache worker behavior all shape what attackers can do next.

IOCs

Type	Indicator	First Seen	Last Seen	Description
IPv4	85.11.187[.]35	2026-10-21	2026-10-21	Exploitation attempt
IPv4	172.206.2[.]199	2026-10-25	2026-10-25	Scanner + exploitation attempt
IPv4	3.37.227[.]134	2026-10-21	2026-10-21	Exploitation attempt
IPv4	103.151.172[.]95	2026-10-25	2026-10-25	Exploitation attempt
IPv4	178.249.214[.]6	2026-10-24	2026-10-24	Exploitation attempt (VPN)
IPv4	31.56.197[.]72	2026-10-21	2026-10-21	C2 (payload server)
IPv4	135.136.19[.]197	2026-10-26	2026-10-26	Scanner + exploitation attempt (VPN)
IPv4	15.204.59[.]70	2026-10-24	2026-10-24	Exploitation attempt
IPv4	162.35.99[.]94	2026-10-24	2026-10-24	Exploitation attempt