Skip to main content

BUSINESS • 29 October 2026 • 3 min read

After PHP2Shell: what your provider should prove

Before accepting a PHP2Shell update as complete, ask for evidence of the fix on every live site and a clear account of any remaining investigation.

The PHP2Shell security release on 21 October 2026 addressed two critical flaws in PHP, the software that runs Drupal. Ask your provider for a short completion report answering these five questions.

1. Who owned the response?

PHP may be maintained by your hosting provider or packaged in a container that your application team must rebuild and deploy. Establish who was responsible for your site's PHP runtime and who coordinated the response.

The report should identify the affected sites and environments, their responsible providers and one accountable contact for any unfinished handover.

2. Is the fix running on every live site?

Require a recent confirmation that each live service is using the required fix, linked to the relevant PHP or vendor advisory. Include applicable follow-up guidance. Vendors can backport security fixes into older packages, so version numbers need supporting vendor evidence.

List services still awaiting deployment or verification, including failed updates and sites that stopped reporting. A merged change or successful test is only part of the completion record.

3. Did the fix meet the deadline?

Record the applicable contractual or organisational deadline, the event that starts its clock, when the production change took effect and when it was verified.

Classify the result as confirmed on time, confirmed late or timing unverified. Use release records to establish deployment timing when verification happens after the deadline.

4. Was possible earlier compromise assessed?

AWS observed exploitation attempts from 17 October, before the public fixes. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue on 26 October. Updating promptly cannot rule out an earlier compromise.

The Drupal Association recommends preserving evidence and reviewing activity from 17 October. Ask what was retained, what was examined, what was found and what could not be checked. Evidence should be secured before routine log rotation or infrastructure replacement removes it.

Missing logs must appear as a limitation. Suspicious findings need an investigation owner and next action. The provider's conclusion should reflect the evidence available.

5. What remains open?

Every outstanding item needs a named owner, next action and review date. The patching task can close while an investigation continues, provided that investigation remains assigned and tracked in a linked record. Record who accepts any residual risk and why.

Before accepting incident closure, require the investigation outcome and an explicit handover of any remaining work. Use gaps in the report to agree clearer ownership, evidence retention and release arrangements before the next advisory.

For background, see What is actually running on your Drupal websites?. Your technical team can use the Sentinel fleet-monitoring guide to establish recurring site observations.

Customer experience

Organisations TrueCMS has worked with

  • Omni Environmental Group
  • XADO
  • RedyHost
  • Tilkah
  • Quantum BioTek
  • Australian Citizens Party
  • DPV Health
  • Supervision Training Services