PHP Site AuditDrupal
Does PHP2Shell affect Drupal websites?
Composer manages Drupal core, contributed packages, and their PHP-library dependencies; it does not patch the PHP interpreter installed by the host. Build and test the Drupal dependency change from the project’s Composer files, deploy the locked code and required database/configuration updates, and separately ask the runtime owner for package and worker-restart evidence. Record which environment each proof covers.
Know what Composer controls
A Drupal Composer project describes application dependencies in composer.json and pins resolved package versions in composer.lock. Drupal’s documentation recommends Composer for managed core and module updates, and its deployment guide describes building the deployed code from the lock file. Those files are important release evidence: they show which Drupal and library code the project intends to use. They do not name or replace the operating-system PHP runtime that executes web requests.
What Composer does not update
That distinction matters during a PHP-core security response. Running Composer update may change Drupal packages or libraries, but it does not install a patched PHP package, update a container base image, or restart PHP-FPM or another web handler. Conversely, a host can patch PHP without changing the Drupal lock file. Track these as linked but separate work items so one green deployment does not accidentally stand in for the other.
Check Drupal and dependency compatibility
Have the Drupal maintainer check the PHP requirements for the exact core and contributed-module versions in use. Drupal notes that a dependency can change supported PHP requirements during a Drupal release line, so compatibility needs to be checked against the installed versions rather than guessed from a general CMS label. On a development or staging copy, resolve the intended dependency changes, inspect and commit both composer.json and composer.lock, and exercise the project’s normal deployment process.
Deploy the reviewed lock file and Drupal updates
Drupal’s deployment guide describes resolving and testing Composer changes before deploying the committed composer.lock. On the target server, install the recorded dependencies rather than resolving a new set there; then run the project’s documented database-update, configuration-import/export and cache-rebuild steps as applicable. Review the Drupal status report and errors, and test as an anonymous user. Keep the tested lock file, code artifact and database/configuration work tied to one release record.
Ask for runtime evidence and verify Drupal
The infrastructure owner should identify the PHP package or managed runtime serving each Drupal environment, the applicable vendor advisory for the October PHP-core CVEs, the installed package or image revision, and the time the relevant web workers were restarted. Include the environment name and origin/pool mapping. If a host uses a backport, request the vendor’s evidence for the exact OS release and package stream; a bare upstream-looking version is not enough.
After both tracks are done, verify the Drupal status report and representative public and authenticated flows, then compare the runtime evidence with the ticket. A Drupal status page or application health route can tell you about application behavior, not package contents. If the application deploy passed but the runtime owner has not supplied matching evidence, label runtime remediation unknown and leave that task open.
If deployment includes a database schema change or configuration import, note that explicitly in the release record and follow the site runbook for backups and recovery. Keep the tested artifact, lock file, and runtime evidence aligned to the same release candidate. If an environment cannot be rebuilt from those records, document it as a deployment exception before declaring the update repeatable.
Common questions
Does composer install install a PHP security patch?
No. It installs project dependencies from the lock file; the host or image owner updates the PHP runtime.
Should production run composer update?
Follow the Drupal project’s deployment method. Drupal’s lock-file workflow resolves and tests dependencies before deployment, then installs the locked result.
What if the lock file is current but PHP evidence is missing?
The application dependency track may be complete, but runtime remediation remains unverified until the serving package and restart are confirmed.