A DigitalOcean PHP update is complete when the corrected runtime is serving the intended workload and the application's important functions have been tested. Start by finding where PHP runs, identify who controls each package or image, then record the deployed result. A new template, a successful image build or a dashboard version alone cannot close that work.
This guide turns a hosting alert into an inventory and acceptance record. The examples are proposed checks for your operator to adapt, not findings about your account. Keep runtime deployment here and use the linked platform guides for the application's own workflows.
As of 23 October 2026, the original incident concerns CVE-2026-109618 and CVE-2026-109619. The PHP releases and incident guidance holds the initial release table and vendor-backport caveats. Select a compatible fix using PHP's advisory and your package supplier's current evidence.
DigitalOcean's public incident advisory identifies customer workloads that need attention, including installed PHP on Droplets and PHP-containing containers. It also distinguishes App Platform buildpack applications from custom images. Treat that notice as a reason to inspect your deployment; it does not establish that a particular account was exploited or that someone has completed its remediation.
Review the separate 23 October PHP follow-up, CVE-2026-115560, with the application maintainer. Its applicability involves an unusual configuration and application behaviour. Record that assessment separately from the original patch rather than assuming that every workload is affected or every later issue is resolved.
List projects, environments and the person able to change each deployment. Start with the public website, then add administration tools, older subdomains, test environments reachable from the internet, import services and scheduled jobs. Ask the team what still receives requests or processes data, including components outside the main website's deployment pipeline.
Use one row per independently deployed workload. A server can host several sites with different runtime arrangements, while one application can use several containers or processes. Record those relationships without putting credentials or customer records into the inventory.
| Workload to inspect | Evidence to plan | Person to identify |
|---|---|---|
| PHP installed on a Droplet | Supplier package revision and active service | Server operator |
| Custom container | Corrected build and deployed image reference | Image and deployment owner |
| DOKS application | Application rollout and running workload images | Cluster application operator |
| App Platform component | Build method and completed deployment | Application operator |
| Existing Marketplace-derived instance | Current installed runtime | Maintainer of that instance |
| Recovery image or snapshot | PHP verification before restored use | Recovery owner |
Mark a row as unknown when access or evidence is missing. Do not infer its state from a neighbouring server. Agree who will resolve the unknown, what access they need and whether the workload should remain publicly reachable while the operator assesses it.
DigitalOcean's Droplet responsibility model separates provider and customer responsibilities. Name the person or contracted team responsible for the guest operating system and installed application software. Buying infrastructure and appointing someone to maintain a custom application are separate operational decisions.
Ask that operator to identify the distribution release, package source, installed package revision and relevant security notice. For Ubuntu, for example, USN-8948-1 lists release-specific fixed packages. It is evidence for the listed Ubuntu packages, not a universal version instruction for another distribution or a custom PHP build.
Agree the update and service activation steps for the actual configuration. Record which web service, PHP process pool and background process uses the corrected runtime. If multiple PHP installations exist, distinguish the command-line executable from the runtime serving requests. Ask for the connection between the package record and the active service, rather than accepting an isolated screenshot.
Keep the evidence private and minimal. A public server-information page can disclose details that do not belong in a handover. The record should identify the workload, package evidence, activation time and reviewer without exposing environment secrets or unrelated account information.
For an image-based workload, separate building, storing and deploying. Identify where PHP enters the image: the base image, an installation step or a bundled component. The image owner selects the applicable corrected source and rebuilds through the agreed pipeline. Record the resulting image reference so the operator can identify precisely what was approved.
DigitalOcean's image-to-cluster guide illustrates the path from a built image through a registry to a Kubernetes application. Use your own deployment configuration and permissions for the production change. A registry upload is one step in that path, so request evidence of the workload that actually consumes the new image.
Kubernetes documents how Deployments manage rollout state. Have the operator check the intended image, rollout completion and the workloads still serving requests. Identify jobs, workers or other controllers separately where they are used; checking one Deployment does not inventory the entire cluster.
Agree how to handle old replicas and interrupted work before replacement. Record whether a queued task can finish, be retried or require manual reconciliation. The acceptance decision should include the application's observed result, with any failed or incomplete task assigned to an owner. Do not promise uninterrupted service from a deployment method alone.
First identify whether the component builds from source with a buildpack, uses a Dockerfile or deploys a prebuilt image. DigitalOcean's incident notice says its PHP buildpack was patched and directs application redeployment; custom images require their own corrected PHP and redeployment. Verify the path your component uses rather than transferring one product statement to another setup.
For source builds, consult the restart and rebuild documentation. Restarting an existing container and producing a new build are different operations. Ask the operator to choose the operation that incorporates the intended runtime change, review its build output and record the resulting deployment.
For prebuilt images, the container deployment documentation describes image tags, digests and deployment behaviour. Capture the image reference selected by the deployment and compare it with the approved build. Do not assume that pushing an image to any registry automatically replaces the running application.
Use the deployment management view to connect the change to a specific deployment and its logs. Record the relevant service and worker components, who reviewed their startup and what application check followed. A deployment marked successful still needs the business acceptance agreed for that application.
Before changing production, agree a maintenance window, responsible operator, business reviewer and communication route. Identify which submissions, orders or scheduled work might be active during the change. A protected staging test is useful where available, provided its external connections and data have been prepared for testing.
Identify the recovery materials and how they fit together: code or images, database, uploaded files and configuration. Ask who can restore them and how later writes will be reconciled. Record the PHP state required after recovery so that restoring an older image does not silently become an unreviewed runtime decision.
Define the stopping conditions. An unavailable login, unexpected access to a private file or a duplicated business action needs a named decision-maker. Consider both availability and security when choosing recovery, containment or a forward correction. Leave the decision and its evidence in the change record, including any temporary restrictions.
Choose checks around the functions the organisation relies on. Use approved sample records and accounts representing real roles. The following is a proposed matrix, not a claim that every custom PHP application supports these functions.
| Proposed check | Evidence to agree before the change |
|---|---|
| Sign in and recover an account | Correct account receives the permitted result |
| Upload and retrieve a file | Valid upload works; unauthorised retrieval is refused |
| Submit an enquiry or order | One intended record and downstream notification |
| Run scheduled or background work | Expected final state, including retry handling |
| Call a critical integration | Accepted and rejected requests behave as agreed |
Record failures as well as successful requests. Trace a form submission to its destination instead of stopping at the thank-you page. For repeated background work, check whether the first attempt already changed business data before approving another attempt. Use the application's normal audit trail where available and avoid copying sensitive payloads into the release report.
For WordPress or a store, use the WordPress forms and checkout acceptance guide. For Laravel, follow the Laravel deployment and background-work checklist. For an editorial CMS, use the Drupal publishing and document-access checks. Keep those application results attached to the corresponding infrastructure row.
Ask the maintainer to separate the immediate security decision from a wider compatibility migration. PHP's advisory describes vendor backports and limited source backports for some older branches. Ubuntu's older-release security notice is one example of supplier-specific coverage; eligibility and package evidence must match the actual system.
Do not repeat an absolute claim that no older-version fix exists, and do not describe an exceptional fix as renewed normal upstream support. Document the chosen short-term route, its responsible supplier and the plan for a supported environment. Assess framework, libraries, extensions and custom code before agreeing the destination branch.
Use the legacy application migration planning guide for broader sequencing. Keep the incident response active while compatibility work proceeds, with current official guidance and the operator's assessment informing any temporary restrictions. A migration estimate does not by itself resolve an exposed workload.
Close each inventory row with the applicable advisory, package or image evidence, active deployment, application results and remaining exceptions. Include the separate follow-up assessment, reviewer and next maintenance owner. An untested component stays explicitly pending, even when the main site works.
Patching and functional tests cannot establish that an earlier compromise never occurred. If compromise is suspected, agree investigation and recovery with the responsible team; NCSC's PHP response guidance provides incident context. Keep that investigation distinct from the deployment acceptance recorded here.
The takeaway is a traceable chain from the applicable fix to the running workload and its tested business result. Use that chain to review completion across the inventory, rather than one green dashboard status for the whole account.
TecnoStack can review the setup, agree compatible patching or an upgrade path, verify the deployed runtime and test the functions included in the engagement. Discuss your DigitalOcean PHP update alongside the infrastructure and recovery scope. Complex containers, Kubernetes changes, application modifications, investigation and continuing care require separate assessment where needed.
Request a PHP security assessment. Send the website address, platform and hosting arrangement, PHP version if known, critical functions and any suspicion of compromise. Include maintenance constraints and the person who approves the change. Keep passwords, API keys and customer records out of the initial message; scope, timing and price follow review.
