Drupal Association blog: After the PHP security release: auditing your Drupal sites

First things first: if you have not yet updated PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your host's or distribution's patched build), do that right away. See PSA-2026-10-20 from the Drupal Security Team and the PHP project's security advisory. Updating is the only complete fix for CVE-2026-109618 and CVE-2026-109619, and a configuration change or web application firewall rule does not replace it.

It feels like the whole internet has come together to address this PHP vulnerability. It is rare to see that much coordinated effort, and that much care and collaboration.

This post is about what comes after the update. On 21 October, Amazon Threat Intelligence reported that its honeypots recorded an exploitation attempt on 17 October, four days before the vulnerabilities were public, and further attempts in the hours before the fix was released. Amazon does not know whether those early attempts would have worked against real systems. But it means a site that updated promptly on 21 October was still exposed for several days beforehand, and a site that updated later was exposed for longer. Patching closes the door; it does not tell you whether anyone came through it first.

These vulnerabilities are in PHP itself, not in Drupal, so there is no Drupal-specific signature to look for, and no single checklist that fits every site.

Here is how the Drupal Association is handling it for Drupal.org: we updated, and we are now auditing our own infrastructure for signs that anything reached us before the update. In doing that research we have assembled the checks below, the help from an LLM. Not every one of them applies to every site, and which ones should be run depends on the host, but this is what our reading of the advisories and the published threat intelligence leads us to believe site owners should consider, whether they manage their own servers or want to ask their host the right questions. None of these findings is proof of compromise on its own. What you are looking for is several of them clustering around the same time or the same visitor.

Keep the evidence before you look

The audit window starts on 17 October 2026. Before you redeploy or rebuild a server you want to examine, copy its web server, PHP-FPM and system logs somewhere safe. If you run in containers, a redeploy discards everything inside the old container, so capture it first (docker diff or docker commit on the running container) and only then roll the new image.

Where to look

Web server and proxy logs

Start with the simplest check. Amazon published six source addresses in its report:

• 103.216.220.92 (seen 17 October)
• 31.223.184.166 (seen 21 October)
• 37.19.200.5 (seen 21 October)
• 134.209.159.64 (seen 21 October)
• 103.114.163.188 (seen 21 October)
• 95.217.98.37 (seen 21 October)

Search your access logs from 17 October onward for any POST, PUT or PATCH request from those addresses. They belong to shared anonymisation services, so a match is a reason to look harder at that server rather than proof of anything, and no match proves nothing either; a honeypot sees a sample of attackers, not all of them.

Then look at request shape. One of the two bugs is reached through multipart form uploads, so what you are looking for is a run of multipart POST requests from a single visitor to a page that does not normally receive uploads: the front page, a node, a JSON:API route. Browsers do not send multipart bodies on PUT or PATCH, so any of those are worth a look on their own. The other bug is reached by pushing PHP out of memory, which from the outside looks like bursts of large or oddly shaped requests from one client, often paired with a cluster of 500, 502 or 503 responses on a URL that otherwise returns 200. A quick first pass on an Apache or nginx access log is to count POST, PUT and PATCH requests by client address and then read the top few clients' requests in full.

PHP and web server error logs

A failed attempt at a memory-corruption bug tends to leave a trail that a successful one may not, so this is often the richest source. Look for clusters of Allowed memory size of N bytes exhausted, Out of memory, Maximum execution time exceeded, and PHP fatal errors that name no script. In the PHP-FPM log, look for worker crashes: child N exited on signal 11 (SIGSEGV) or signal 6 (SIGABRT); in Apache, exit signal Segmentation fault. A few of these scattered across weeks is normal for a busy Drupal site. Dozens within minutes, or any at all from a single client, is not.

grep -hE 'exited on signal|Segmentation fault|memory size of|Maximum execution time' \ /var/log/php*-fpm.log /var/log/apache2/error.log /var/log/nginx/error.log 2>/dev/null \ | cut -c1-120 | sort | uniq -c | sort -rn | head -20

PHP's own session store

This applies to Drupal sites too, not only to other PHP applications sharing the server, and it surprises people. Drupal stores its sessions in the database, but it registers that handler during bootstrap, and the PHP feature involved in one of these bugs (session upload progress) runs earlier than that, while PHP is still parsing the request body and before a single line of Drupal has executed. At that point PHP knows only its own native session handler, so the write lands in the directory named by session.save_path, typically /var/lib/php/sessions. On a Drupal site that directory should be nearly empty and nearly static, which makes anything in it from the past week worth a look. Look for files created around a suspicious burst, session IDs that are not the usual 26 to 32 alphanumeric characters, and any file containing a PHP open tag or an upload_progress_ key.

ls -lat --time-style=full-iso /var/lib/php/sessions | head -40 grep -l '<?' /var/lib/php/sessions/sess_* 2>/dev/null grep -l 'upload_progress_' /var/lib/php/sessions/sess_* 2>/dev/null

The filesystem

List files created or changed since 17 October in places a deployment does not touch: the public and private files directories, the temporary directory, PHP's upload directory, and anywhere else the web server user can write. A .php, .phtml or .phar file in a files directory, a changed .htaccess there, or a new hidden file is the classic web shell pattern. Timestamps can be faked, so also compare the deployed code against its source of truth: git status on a git-deployed site, or a diff of vendor/ and core/ against a clean composer install from the same composer.lock.

find /var/www -newermt '2026-10-17' -type f \ -not -path '*/vendor/*' -not -path '*/node_modules/*' -not -path '*/.git/*' \ -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort | tail -100 find /var/www -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -path '*files*'

Processes, connections and persistence

The web server user (www-data, apache, nginx) should own PHP and web server processes and nothing else. A shell, curl, wget, python, perl, nc or anything running from /tmp or /dev/shm under that user is a finding. So are outbound connections from a web server to addresses that are not your database, cache, mail relay or known APIs. Then check the places a compromise of the web user can reach to survive a reboot: crontab -u www-data -l, new entries under /etc/cron.d, new systemd units or timers, changed ~/.ssh/authorized_keys files, and new local accounts.

Drupal itself

Finally, the application layer. Look for user accounts created or changed since 17 October, and for anyone newly holding the administrator role. Run drush config:status against your exported configuration and look for drift, especially newly enabled modules. Check drush watchdog:show --severity=Error for the same fatal errors and memory exhaustion you looked for in the PHP log. Diff settings.php, settings.local.php and services.yml against your deployment source; they hold the database credentials and hash salt an attacker would want.

If you find something

Take the server off the internet, but leave it running if you can; a powered-off machine loses the evidence in memory. Preserve the logs and, if possible, a disk image. Rotate every secret the web server user could have read: database credentials, the Drupal hash salt, API keys, SMTP credentials, and any private keys on the host. Treat other servers that share those secrets or a session store as suspect too. Rebuild from a known-good image or checkout onto patched PHP rather than trying to clean the compromised host in place; it is faster and you will trust the result.

Because these are PHP vulnerabilities rather than Drupal ones, a compromise through them is not a Drupal security issue to report to the Drupal Security Team. It belongs with your own incident process, your host, and, where you have obligations to them, your customers and users.

Hardening worth keeping

Two of the interim settings the PHP project recommended are worth leaving in place after the update. session.upload_progress.enabled = 0 turns off a feature Drupal does not use; the PHP advisory suggests keeping it off if you do not need it. session.use_strict_mode = 1 is long-standing hardening that stops PHP accepting session identifiers it did not issue. Set both in your php.ini or PHP-FPM pool configuration rather than with ini_set(), and restart PHP afterwards. If you temporarily removed PHP's memory limit or set pm.max_requests = 1 during the exposure window, put those back to normal now; they were stopgaps with real costs.

Next steps

Update PHP if you have not. Then spend an hour with the logs, starting from 17 October, before you let the new deployment overwrite them. If your site is hosted for you, ask your host whether they have done the same, and whether their session.upload_progress setting is off. If you have questions or findings that would help other site owners, the #security-discussion channel on Drupal Slack is the place to raise them; please do not post exploit details or anything that identifies a specific compromised site.

Our thanks to the PHP security team for the coordinated release, and to the hosting partners and community members who shared their own validation results with us this week.