By Ivan Grynenko
Across a Drupal fleet, PHP can have different owners and release paths. A completed application release may leave the runtime unchanged, and a new container image may still be waiting for deployment.
Use the following workflow to establish which environments received the PHP2Shell fix, when it took effect and what still needs action.
1. Map the environments and runtime owners
Start with the full production inventory, including sites absent from monitoring. Record each site, environment, application release owner and PHP runtime owner. Identify shared runtimes and repositories, then verify the coverage of any shared deployment.
For provider-managed PHP, obtain confirmation for the specific hosting service. For an application-owned image, identify the build and deployment that deliver the fix.
When the fix comes from a base image, update its pinned digest or ensure the build fetches the updated tag. Deploy the resulting image and record its resolved digest.
2. Identify the required remediation
The PHP advisory of 21 October lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the initial releases fixing CVE-2026-109618 and CVE-2026-109619. Where a vendor supplies backported fixes, retain its advisory and exact package revision.
Check subsequent notices as well. PHP published session-handling guidance on 23 October and Windows package rebuilds for a separate Brotli issue on 26 October. The Windows rebuilds retain the same PHP runtime version, making the package revision relevant.
Record the affected component, advisory, applicability assessment and required fix. Treat temporary mitigations as separate work with a follow-up deadline: the original PHP2Shell flaws require an update for complete remediation. An affected version warrants action; it does not establish that the site was compromised.
3. Connect the release to the running service
Keep three records together for each environment:
| Evidence | Minimum useful detail | Verification question |
|---|---|---|
| Change and build | Release reference, package revision or image digest | Does this artefact contain the required fix? |
| Deployment or provider confirmation | Environment, deployed artefact and completion time | Did the intended service receive it? |
| Fresh production observation | Environment identity, web-runtime details and observation time | Is the serving runtime using the fix? |
Confirm that the observation represents the production web runtime. PHP in a build job or command-line container may differ. For services with multiple serving instances, establish that verification covers them all.
Reconcile disagreements before marking an environment verified. Assign partial rollouts, stale observations and unexpected versions to a named owner.
4. Track timing and exceptions
Store deployment time and observation time separately. A first observation establishes what the environment reported at that time; it cannot establish the exact installation time or uninterrupted protection afterwards.
If the first check is late, use deployment records to assess the deadline. If a rollback restores a vulnerable component, retain the earlier evidence and reopen the exposure.
Set a reporting cutoff and include every expected environment. Use working states such as awaiting provider, awaiting release, deployed awaiting verification, verified, or exception under review. Give each gap an owner and next action.
5. Apply the service's actual deadline
Record the applicable policy or contract, clock-start event and deadline. Ticket creation must not silently reset the security clock.
For online services covered by the Essential Eight maturity model, vendor-rated critical vulnerabilities require patches, updates or other vendor mitigations within 48 hours of release. Confirm the service's current obligations during ASD's transition to the Essentials framework. A patching record supports assessment of that requirement; it cannot establish compliance with the entire framework.
6. Keep the investigation linked and visible
AWS recorded exploitation attempts from 17 October. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue on 26 October.
The Drupal Association's guidance recommends preserving evidence and reviewing activity from 17 October. Coordinate capture before rebuilds or retention policies remove relevant logs and system evidence, while progressing urgent remediation.
Link the investigation record, responsible owner, review period, findings and evidence gaps. Keep remediation verification and compromise assessment as separate outcomes. Absence of a known indicator does not prove the site was never compromised.
Use Sentinel reports alongside deployment evidence
Keep Sentinel Connector site reports alongside release records and runtime-owner confirmation. Treat reported inventory as one input to verification. PHP advisory applicability, vendor backports, production-instance coverage and investigation outcomes need their own supporting evidence.
Use the fleet-monitoring guide for the monitoring foundation. TrueCMS's What is actually running on your Drupal websites? explains the service-owner perspective.
The handover should identify verified environments, evidence gaps and assigned follow-up work. Keep that record current as providers respond, deployments complete and investigations progress.