From an alert to a record you can trust.

01 / Start

Start with a record, before changing the system.

1. Assign an owner. Name who can authorize and perform changes for each asset. Record the decision, time and business impact. Coordinate urgent containment with evidence preservation; do not postpone containment while waiting for a perfect inventory.
2. Preserve what you can safely preserve. Retain existing deployment records, artifact identifiers, relevant logs and provider notices before rebuilding or deleting anything. Store evidence with restricted access. Record who collected it and when. Keep credential values out of the checklist.
3. Identify the deployed and executed artifact. Record the installed version, package source or image digest, build/download time, deployment time and execution times where relevant. A dependency declaration or mutable image tag alone cannot identify what ran.
4. Read the original notice again. Open the vendor source linked in the matching section. Record its update time and the guidance you used. This snapshot can become stale.
5. Let the technical owner execute the response. Record containment, updates, credential revocations and rebuilds separately. Use the current vendor procedure and a trusted environment. Do not treat a successful update as proof that exposed credentials were revoked.
6. Verify and hand over. Check the deployed artifact and application behavior with independent evidence. Assign every unresolved question an owner and a next check. Use the closure record.

One record per asset

Identity

Asset, environment, client or project reference, technical owner.

What ran

Installed version, artifact origin and digest or package build, download/build/deploy/execution times.

Basis

Original advisory URL, access time, applicable interval or incident condition.

Action

Decision, executor, start and completion times, rollback plan, receipt location.

Remaining gap

Unknown fact, evidence needed, responsible person, next check time.

Workflow: editorial synthesis of the PHP advisory, LiteLLM incident report, Railway disclosure and Zeabur announcement. Reviewed 22 October 2026.

02 / Runtime

PHP: compare the running build.

PHP’s 21 October advisory covers CVE-2026-109618 and CVE-2026-109619. It identifies web-serving installations as at risk, with mod_php the highest-risk configuration. The upstream fixed releases are:

Earlier releases within those branches need attention. PHP also supplied minimal source backports for 7.4, 8.0 and 8.1. Distribution packages may carry backported fixes without matching these upstream numbers: obtain the distributor’s advisory and exact package-build receipt.

Record the runtime serving requests, including every worker or replica. A CLI version, control-panel setting or successful build alone does not establish the version serving production traffic. After the owner updates and restarts or redeploys as required, retain a runtime receipt and application smoke-test results.

Sources: PHP’s 21 October advisory, out-of-memory corruption advisory, stale global state advisory. Snapshot: 22 October 2026.

03 / Source hosting

GitLab: use the exact affected interval.

GitLab rates CVE-2026-110264 at CVSS 3.1 10.0. Under certain conditions, the regular-expression compiler flaw could allow unauthenticated code execution. The advisory gives these GitLab Community Edition and Enterprise Edition intervals:

These are vulnerability boundaries, not instructions to skip required upgrade steps. The owner must follow GitLab’s current upgrade path and migration guidance. Record the installed edition, build and deployment type.

GitLab says its managed infrastructure is patched. Its notice identifies fixed internal builds for Dedicated. Use the provider’s current receipt for your deployment; do not label every GitLab service affected. A patched version alone cannot rule out earlier compromise.

Source: GitLab’s critical patch advisory, “CVE-2026-110264,” detection guidance and upgrade notes. Exact intervals checked against official search-returned text on 22 October 2026; direct page retrieval failed.

04 / Release artifacts

LiteLLM: do not start the affected interpreter.

The vendor identifies all seven PyPI wheels for version 1.107.0 and affected Docker Hub/GHCR artifacts. It reports that the public source tag was clean. A clean repository therefore cannot establish that an installed release artifact was clean.

Affected tags included v1.107.0, latest, main-latest and main-stable. Preserve artifact identity and download, build, deploy and interpreter-start times. Cached artifacts may run later than the distribution window.

Use the current vendor response procedure for containment, credential revocation and a clean rebuild. Missing local markers do not prove absence of exposure. A metadata check cannot determine which credentials were read or whether they were used.

Sources: LiteLLM’s incident report, affected artifacts, timeline and remediation warning; Upwind’s upstream report. Snapshot: 22 October 2026. Vendor text retrieved through search; direct page retrieval failed.

05 / Credentials

Railway: track revocation separately from deployment.

Railway’s 21 October disclosure says an unauthorized party may have accessed encrypted environment variables and obtained decrypted contents for some. It recommended rotating stored variables and private-registry credentials for all users as a precaution. This is not confirmation that every customer was breached.

Inventory credential types and owning services without copying secret values into the record. The technical owner should follow the latest notice, replace affected credentials through their issuing providers, update dependent services and confirm the old credentials are revoked. Preserve provider receipts with secret values removed.

Verify both halves: the application uses the replacement successfully, and the issuer records the old credential as revoked. A new deployment proves neither on its own. Keep the remaining exposure question open if the available evidence cannot answer it.

Sources: Railway’s security disclosure and Railway’s live status page. Research date: 22 October 2026.

06 / Migration

Zeabur: restore before you call a backup usable.

Zeabur’s 17 October announcement schedules a wind-down. It describes unauthorized access on 14 October to internal systems and some customer services.

Use the actual server expiry as a planning constraint. The final shutdown date does not guarantee service until then. Data-deletion, final-export and support-closing dates were still unfinalized in the announcement.

Record databases, files, configuration, domains and external dependencies. Choose a destination with the technical owner. Restore into an isolated destination, check record counts and representative files, and run application smoke tests. Record the backup time and the data lost or changed since it. An export file’s existence proves only that a file exists.

Before cutover, agree how to handle new writes, verify the restored application and keep a rollback plan. Retain restore and cutover receipts. Mark migration complete only when the owner accepts the restored service and outstanding data gaps.

Source: Zeabur’s founder announcement, incident account and service shutdown timeline. Snapshot: 22 October 2026. Restore and acceptance steps are this guide’s operational checklist.

07 / Verification

Close the action with evidence. Keep the unanswered question.

Separate the action from the conclusion. “Updated” describes work. “The production runtime reports the fixed build at this time” describes evidence. Neither establishes that an earlier compromise never occurred.

Obtain the receipt from the running system or issuing provider, independently of the change command’s success message. Have another person review it when available. A solo operator can use a separate read-back and record that no second person reviewed it.

End the record with the owner’s decision, evidence locations, unresolved questions and next check time. Keep “exposure unknown” if logs, artifact identity or execution history are missing. Do not turn an empty search result into a clean bill of health.

Verification checklist: editorial synthesis of the PHP update notice, LiteLLM response guidance, Railway rotation guidance and Zeabur shutdown notice.

08 / Tabletop

A fictional agency, three open records.

Fictional exercise. These are invented assets and observations, not customer work or evidence of a successful recovery.

No row becomes “safe” because a script prints a version. Each row closes only the question its retained evidence answers.

Example basis: the PHP floors, LiteLLM execution warning and Zeabur schedule above, each linked to its original source.

09 / Take it with you

Free downloads. Read-only checks.

Read each script before running it. Use a trusted machine. These tools collect or compare narrow observations; they do not patch systems, revoke credentials, assess compromise or certify recovery.

node check-php-version.mjs 8.3.35

bash inspect-litellm-metadata.sh /path/to/site-packages

Tool comparison sources: PHP advisory and LiteLLM incident report. Tools and guide use the 22 October 2026 snapshot.

Original sources.

Checked 22 October 2026. Read the latest vendor revision before making changes; this guide is a fixed snapshot.

• PHP security announcement and fixed releases
• GitLab critical patch advisory
• LiteLLM vendor incident report and the original researcher issue
• Railway security disclosure and current service status
• Zeabur wind-down announcement

Retrieval limit: GitLab and LiteLLM vendor text was available through search results when direct page opening failed. The original LiteLLM researcher issue was also reviewed. Workflow and recovery checklists are editorial synthesis; they are not vendor certification.