A Drupal PHP security update needs a verified fix to the runtime serving the site, followed by tests of publishing, access and important integrations. Ask the hosting operator for evidence of the active PHP package or image, and give the Drupal maintainer a separate application checklist. Updating core or a module does not establish that the runtime changed.
This playbook gives site owners, editors and maintainers a practical release record. Its scenarios are proposed acceptance tests, not findings from a customer website. Choose the ones your site actually supports, assign an owner and record the result before closing the work.
As of 23 October 2026, PHP's original incident concerns CVE-2026-109618 and CVE-2026-109619. Our PHP incident version reference contains the initial fixed releases and older-version caveats. The appropriate package or image must be confirmed for your environment; a matching version label alone may not describe a vendor's backported patch.
Drupal's PHP public service announcement directs owners to update PHP themselves or coordinate with the host responsible for it. Its remediation advice concerns PHP. Keep unrelated Drupal core, module and theme advisories in their own tracked work, using each advisory's affected releases and instructions. Do not describe this PHP notice as a Drupal core patch.
PHP's separate 23 October session-upload-progress notice identifies CVE-2026-115560 under an unusual configuration combined with application behaviour. Ask the maintainer to assess applicability and current mitigation guidance separately. This follow-up does not justify claiming that every Drupal installation has the relevant configuration, or that the original update closes every later advisory.
Start with an inventory of sites, domains and environments. Include public staging copies, older campaign sites, separate import processes and scheduled work. Record the responsible host, deployment owner and business contact for each. A confirmation about one production site should not silently cover other installations on the same account.
Keep an identifiable record for each layer. Drupal's security and regular updates guide distinguishes updates to core, modules and themes; your operating arrangement must also cover the PHP runtime beneath them.
| Layer | Person to identify | Evidence to request |
|---|---|---|
| PHP package or container | Hosting or infrastructure operator | Applicable fix and active service confirmation |
| Drupal core and dependencies | Application maintainer | Tested release and dependency record |
| Modules, themes and custom code | Maintainer with application knowledge | Compatibility decision and affected functions |
| Editorial and customer workflows | Named business reviewer | Agreed tests, actual results and exceptions |
Ask who can stop the change if a critical function fails. Where several suppliers share responsibility, make the handover explicit: the host confirms runtime activation, the developer verifies the application, and the owner accepts the business result. Record missing access or ownership before the maintenance window.
Identify the exact Drupal release, installation method and custom components before choosing instructions. Use Drupal's update documentation for the relevant application path. Do not copy a command from a newer installation into an older site without checking its suitability, and do not make an unrelated major upgrade an accidental part of urgent runtime work.
Prepare a protected staging environment where feasible. Use representative test content and accounts, with external email, payment or customer-system connections directed to agreed test destinations. Tell editors which environment they are using. A visually identical staging copy can otherwise lead to someone approving content in the wrong place.
Agree the recovery materials and who can access them: application code, database, uploaded files and relevant configuration. Ask the operator to explain how those pieces are restored consistently. Define how new submissions or edits made after the backup will be handled if recovery becomes necessary; the existence of an archive is not a recovery decision.
Choose a change window with the people needed to verify it. Record the expected publication activity, any approved pause in editing and the communication route if the work takes longer. Do not promise uninterrupted publishing before the application and hosting arrangement have been reviewed.
Request the package revision or image reference, the supplier guidance establishing the fix, and the service restart or replacement record. Ask which active web processes now use it. A shell check, a rebuilt image in a registry and a request served by an updated runtime are different observations; the operator should explain their connection.
Keep runtime evidence separate from the Drupal deployment record. The official Drupal deployment guide covers application code, the dependency lockfile and configuration changes. Ask the maintainer which application steps are needed for this particular release rather than assuming that every PHP package change needs the same Drupal procedure.
Use an agreed private channel for diagnostic evidence. Do not publish a server-information page to prove the version. Record only the details required for the handover, with secrets and unnecessary customer data removed from screenshots and logs.
For a neighbouring Laravel application, use the separate Laravel runtime and worker verification guide. Its worker examples should not be copied into a Drupal ticket as if both deployments had the same process manager or application commands.
Use ordinary test accounts representing the roles configured on your site. Drupal's roles and permissions documentation explains how permissions govern actions. An administrator's successful test cannot establish what an author, reviewer or anonymous visitor can do.
Create a harmless test page using an agreed content type. Save a draft, preview it, submit it for review if that workflow exists, and publish it using the permitted reviewer. Check the visitor-facing page after each relevant transition. Agree beforehand whether an unpublished revision should be visible and to whom, then verify that actual behaviour.
| Proposed journey | Acceptance evidence to agree |
|---|---|
| Author saves a draft | Correct content, author and restricted visibility |
| Reviewer approves a page | Intended revision reaches the public page |
| Editor uploads an image | Image, alternative text and display remain correct |
| User without approval permission tries to publish | Request rejected and publication state unchanged |
| Editor withdraws test content | Agreed removal state visible to visitors |
Record the account role, content reference, time and observed result. Include a failed transition rather than testing only the successful path. Our content structure and editorial planning guide helps explain which content types, relationships and approval steps belong in that acceptance list.
Drupal distinguishes interface, configuration and content translation in its translation concepts guide. For your site, agree which fields and messages should change by language and which should remain shared. Do not infer the expected behaviour simply from the presence of a language switcher.
Run a proposed bilingual publishing test with equivalent Arabic and English content. Check the correct URL, language switch, navigation label and public revision in each language. Inspect right-to-left layout, image alternative text and any attachment whose language matters. Compare the visible result with the editor's selected language, including after a cache refresh performed through the site's normal process.
Test a form in each language using approved sample data. Confirm validation messages, the stored submission where applicable, and delivery to the intended recipient. Check whether confirmation text identifies the correct enquiry. A thank-you page alone does not establish that the message reached the business team.
If the organisation also operates WordPress, use the separate WordPress ownership and checkout checks for that site. Keep each platform's results and host confirmations distinct even when the same supplier supports both.
First agree which documents are meant to be private and the users allowed to retrieve them. Use a non-sensitive test file. Check its direct link as an authorised account, a different ordinary account and a logged-out visitor, following the site's policy. Hiding a link from a menu is not sufficient acceptance evidence for a protected document.
Include the expected download, preview and attachment paths where present. Verify that an access denial does not disclose the document contents. Record the policy being tested and the observed response without placing a real confidential document into the evidence package. Any unexpected access requires an explicit decision before the affected function returns to normal use.
Drupal's cron concepts guide describes periodic maintenance work. Identify the tasks and external integrations used by this installation, their execution owner and the expected outcome. Follow a permitted import, scheduled task or notification through to its final result; a scheduler entry alone does not demonstrate completion.
Agree how to investigate a failed or repeated integration before retrying it. Ask whether the first attempt already created a record or sent a message. Let the application owner approve the retry and record the resulting business state, especially where another system receives the data.
Close with a concise record: affected installations, runtime fix, follow-up assessment, application release, test results, remaining exceptions and the owner of each next action. Confirm who will review subsequent errors and when. Leave untested functions explicitly pending so another maintainer can continue without reconstructing the work.
If a critical test fails, stop the affected release decision and use the agreed recovery plan. Consider the security effect of restoring an older runtime as well as whether the site starts working again. For an installation needing wider compatibility changes, use the staged legacy upgrade planning guide to separate the immediate response from longer-term migration.
Successful patching does not establish that no earlier compromise occurred. Follow the operator's incident process when compromise is suspected; NCSC's PHP incident guidance provides response context. Investigation and recovery are separate work from the functional acceptance tests proposed here.
The practical takeaway is a matched pair of records: the operator proves the runtime change, and the application team records the publishing, access and integration results. Both need named owners and a clear list of unfinished work.
TecnoStack can assess the installation, agree a compatible PHP update or upgrade path, verify the active runtime and test the Drupal functions included in the engagement. Discuss your Drupal PHP security update alongside the infrastructure scope. Application changes, major upgrades, investigation and continuing maintenance need separate agreement where required; they are not automatically included in a hosting allowance.
Request a PHP security assessment. Send the website address, Drupal and PHP versions if known, hosting provider, critical editorial or customer journeys and whether compromise is suspected. Include maintenance constraints and the contact responsible for approval, but keep passwords, API keys and customer records out of the first message.
We confirm scope, timing and price after review. The handover identifies the runtime evidence, tests performed, agreed hardening and outstanding responsibilities, so the next maintenance decision starts with a usable record.
