PHP2Shell in your server logs: what reached four non-PHP sites, and what to grep for

What is the timeline around the disclosure?

PHP2Shell is the name Wiz Research gave to CVE-2026-109618 and CVE-2026-109619, two unauthenticated remote code execution flaws in PHP (both CVSS v4.0 9.2). The public release was scheduled for 21 October 2026 at 14:00 UTC. Times below are UTC.

Cloudflare's blog says attackers were already changing their payloads before the release, and gives no attempt counts. Counts appear only in a statement on X by Cloudflare's CEO, relayed by The Register; we could not verify them and do not repeat them. As of 22 October we found no confirmed successful compromise reported by any of these sources.

What reached four non-PHP sites, hour by hour?

The log is the one from our 48-hour guide, extended: the web-server logs of four new sites on one server, this one included, running Next.js with no PHP, GitLab or WordPress. This extract is 73 continuous clock hours from 19 October 2026 16:07 UTC to 22 October 2026 16:30 UTC, with 65,847 requests and no gaps. IP addresses were counted, never stored. 3,977 requests (6.0 percent) asked for a path ending in .php. None of the four sites has such files.

The release at 21 October 14:00 UTC splits the data into a "before" window of 46 hours and an "after" window of 27 hours (the last hour is partial). The windows differ in length, so we compare per-hour rates and medians, not totals. Distinct IP addresses cannot be added across hours or windows, so sources are shown per hour or per bucket.

The next table groups the hourly counts into 6-hour buckets in UTC (00:00 to 05:59, 06:00 to 11:59, and so on). "Median sources per hour" is the median of the hourly counts of distinct IP addresses within the bucket.

What the data shows, in order of how much weight it can bear:

• The .php request rate is flat across the release. The median is 38 per hour before and 37 after. The mean is a little higher after (58.5 against 52.1), driven by a few busy hours, and the busiest single hour was before the release, on 20 October.
• Distinct sources per hour crept up (median 18.5 before, 21 after). Over whole windows, 379 distinct addresses asked for .php paths before the release and 262 after, and 148 appear in both. These window totals are not comparable because the windows differ in length.
• Around Cloudflare's 03:02 UTC rule start on 21 October there was no jump: the hours 03:00 and 04:00 UTC had 56 and 32 .php requests. The pre-release hours of 21 October ran between 23 and 100 per hour, with the highest at 05:00 and 06:00 UTC (99 and 100), eight hours before the release. The hour of the release itself (14:00 UTC) had 29.
• The only visible rise comes on 22 October: 91 in the 01:00 hour, 173 and 188 at 03:00 and 04:00, 233 at 09:00. That is also when the .php share peaks (15.2 percent in the 00:00 to 05:59 bucket), partly because total traffic per hour was lower than on 19 and 20 October. These are single hours inside a range the data had already shown before the release, and the paths in them look like the usual ones. We cannot tie them to PHP2Shell.

What did the `.php` requests ask for?

Before the release 2,397 .php requests came in, after it 1,580. /wp-admin/install.php is the largest single path in both windows (43.1 percent of .php requests before, 45.9 percent after), and its hourly rate is similar. Debug-page probes (phpinfo.php and its many folder variants, info.php, test.php) are steady, and wp-login.php and xmlrpc.php were, if anything, less frequent per hour after. Config-style names such as wp-config.php entered the top 20 after the release, with small counts. Across the whole extract, 48 requests asked for the PHPUnit test runner file eval-stdin.php under eight different folder names, six each. That file is a known, years-old exposure in PHPUnit test setups left on a public server. It is not part of PHP2Shell, and our logs do not split it by period.

These are lookups for files that tell a scanner what a host runs. A request that asks whether phpinfo.php exists is reconnaissance. It is not an attack on the two CVEs, which the advisories describe as parsing flaws in how PHP handles a request body.

Did we see the request shape PHP2Shell needs?

No. The advisories and vendor write-ups describe the trigger as unusual multipart/form-data POST requests, with no specific endpoint required. Of the 3,977 .php requests, 3,901 were GET and 76 were POST. The logged content type tells the rest: 60 POSTs were application/x-www-form-urlencoded, the standard encoding of a login or contact form, and 16 had no content type. None was multipart/form-data.

That is a clean result for a narrow question and a weak one for a broad one. Our sites run no PHP, so even a perfect exploit request would have found nothing to run, and a scanner may skip a host that does not answer like PHP. Our logs record headers and paths, not request bodies. We can say: during the hours we have, nobody sent these hosts a PHP2Shell-shaped request. We cannot say how many were sent to PHP sites. AWS, watchTowr and Cloudflare report attempts against hosts that do run it.

What should you look for in your own logs?

The signals below are the ones Wiz, AWS and the PHP project publish for log review. None of them proves a compromise, and some also match harmless events. They tell you where to look. If you have not updated yet, do that first: the patch section of our 48-hour guide lists the fixed versions and how to check which PHP serves your site.

Default access logs do not record the content type, so a POST-only grep shows more than you want to read, but it is the only one that works on an unchanged setup. This lists every POST to a path ending in .php in an nginx or Apache log in the combined format, then counts them per source address. A pretty URL or /index.php/route path needs the pattern \.php without the closing quote:

grep -E '"POST [^ "]*\.php' access.log
grep -E '"POST [^ "]*\.php' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

To see multipart bodies in the future, add the content type to the log format. In nginx, add "$content_type" to a log_format; in Apache, add "%{Content-Type}i" to a LogFormat. With the content type as the last quoted field, this finds multipart POSTs:

grep -E '"POST [^"]*" .*"multipart/form-data' access.log

Bursts of HTTP 500 are visible in the default format. This counts 500 responses per minute (the status is field 9 in the combined format) and prints the ten busiest minutes:

awk '$9 == 500 {print substr($4, 2, 17)}' access.log | sort | uniq -c | sort -rn | head

Caddy writes JSON access logs, with the request headers included. These jq filters list multipart POSTs to PHP URLs and count 500 responses per minute:

jq -c 'select(.request.method == "POST"
  and ((.request.headers["Content-Type"][0] // "") | startswith("multipart/form-data"))
  and (.request.uri | test("\\.php")))' access.log

jq -r 'select(.status == 500) | .ts | floor | strftime("%Y-%m-%d %H:%M")' access.log | sort | uniq -c | sort -rn | head

The remaining signals live in other files. The first two lines search the PHP error log for the standard memory-limit message and the PHP-FPM log for a worker that died; paths differ by system (for example /var/log/php8.3-fpm.log on Debian). The third needs a log that stores request bodies, such as a WAF audit log:

grep -i 'allowed memory size' /var/log/php_errors.log
grep -E 'exited on signal|exited with code [1-9]' /var/log/php8.3-fpm.log
grep -l 'PHP_SESSION_UPLOAD_PROGRESS' /var/log/waf-audit.log

One match is a reason to look, not a verdict. A memory-limit error can come from a slow plugin and a restarted worker from a deploy. A cluster of them, shortly after a multipart POST from one address, deserves a closer look at that address and at what ran on the server afterwards. If you think the server was hit, treat it like any suspected code execution: take a copy of the logs and the file system before you change anything, and rotate secrets stored on that host.

What the data cannot show

• Coverage. 73 continuous hours, from 19 October 16:07 UTC to 22 October 16:30 UTC. Our logs start after AWS's 17 October attempt, so that day is not covered.
• Scope. Four small new sites on one server, three days, no PHP.
• Bodies. We log request paths, headers and status codes, not bodies. A multipart POST that our server did log would show up as such; we saw none.
• Attribution. We cannot say which scanner belongs to which campaign, or that any hour reflects PHP2Shell specifically.

Checked 22 October 2026. Sources: AWS Security Blog, Cloudflare, CISA alert, Wiz, php.net archive, PHP Foundation.