Drupal Association Audits Drupal.org After PHP2Shell Fixes

Following the emergency PHP security releases on 21 October 2026, the Drupal Association reported that Drupal.org had been updated and its infrastructure was being audited for possible suspicious activity before the fixes were installed. The Association published Drupal-specific auditing guidance on 22 October, encouraging site operators to review available server records rather than assume that an updated PHP installation had never been compromised.

The guidance moves the focus beyond fixing vulnerable software to investigating possible earlier exposure. Installing corrected PHP builds addresses the known vulnerabilities, but it cannot establish whether an attacker accessed a system before the update. That distinction matters because attempts to exploit PHP2Shell were observed before public disclosure, leaving an earlier period that site operators may need to examine.

According to an Amazon Threat Intelligence report published on 21 October, the company's MadPot honeypot system recorded a PHP2Shell exploitation attempt on 17 October, four days before public disclosure. CJ Moses, chief information security officer of Amazon Integrated Security, reported that the attempt originated from an IP address associated with a commercial anonymisation network. Amazon subsequently observed additional attempts between approximately 02:00 and 08:00 UTC on 21 October, before the coordinated public release at 14:00 UTC.

Amazon said differences in payloads and anonymisation infrastructure suggested that multiple actors may have been involved. However, the company could not determine how the earliest actor obtained information about the vulnerabilities while they remained under embargo. It also stated that the effectiveness of the observed attempts against real-world systems was uncertain. The findings document attempted exploitation, not confirmed compromise of production Drupal websites.

The underlying vulnerabilities, CVE-2026-109618 and CVE-2026-109619, concern PHP's handling of memory exhaustion and internal state. Both can lead to remote code execution under vulnerable conditions, although their demonstrated attack paths differ. The PHP project released fixes in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on 21 October. Updating Drupal core or contributed modules does not install these runtime fixes.

The Association's auditing guidance identifies several possible sources of evidence, including hosting and web server logs, native PHP session storage, writable directories and Drupal configuration. Such records can help investigators reconstruct activity during the period when vulnerable PHP processes were accessible. Their availability depends on the site's logging arrangements, retention policies and deployment history.

Web server records may reveal unusual upload requests, repeated failures or other activity consistent with known exploitation techniques. Amazon recommends examining POST requests containing the PHP_SESSION_UPLOAD_PROGRESS marker, where sufficient request details have been recorded, along with unexpected process execution and file modifications. Conventional access logs may not retain request-body fields, and a matching request or network address does not independently establish successful exploitation. Amazon also cautions that some reported IP addresses belong to shared anonymisation infrastructure and should be investigated rather than automatically treated as exclusively malicious.

Native PHP session storage warrants attention because certain upload-processing operations occur before Drupal application code executes. The PHP documentation explains that upload-progress information can be written to session data before the requested script starts. Storage locations and the availability of historical records depend on PHP configuration and the hosting environment. Missing session files or an absence of matching entries cannot establish that exploitation did not occur.

Unexpected PHP files, changes within writable directories and alterations to Drupal configuration may provide additional investigative leads. However, legitimate deployments, maintenance operations and administrator activity can produce similar findings. Investigators need to compare timestamps and configuration differences with deployment records, access logs and other evidence before attributing activity to an attacker.

Preserving evidence can be particularly complicated in container-based environments. For example, Docker's documentation states that committing a container to an image does not include data stored in mounted volumes. Its filesystem-difference command identifies changed paths but does not preserve a complete forensic record. Replacing containers or restarting services without accounting for externally stored logs and persistent volumes can leave investigators with an incomplete history. Evidence-preservation procedures must therefore reflect the infrastructure involved, without delaying necessary security remediation.

The Association acknowledges using assistance from a large language model when preparing its suggested checks. These examples should be treated as investigative starting points rather than independently validated forensic signatures. Their usefulness depends on a site's PHP configuration, logging arrangements and available records. Neither an isolated suspicious observation nor an unsuccessful search for known indicators is sufficient to establish the presence or absence of compromise.

For Drupal operators, the immediate priority remains confirming that the PHP runtime serving production requests contains the security fixes, including relevant distributor backports where applicable. The Drupal Security Team's public service announcement makes clear that site owners are responsible for maintaining the security of their hosting platforms and non-Drupal components. Where historical activity raises concerns, hosting providers and qualified incident-response specialists can help preserve records, correlate findings and determine whether further investigation is warranted.

The Association's 22 October statement does not report a confirmed compromise of Drupal.org or a completed audit outcome. Its significance lies in the additional question facing Drupal administrators after the emergency updates: not only whether vulnerable PHP has been replaced, but whether the available evidence can establish what happened while those vulnerable systems were running.