---
title: "A PHP Emergency Patching Playbook for Engineering Teams"
slug: "php-2026-vulnerability-patching-playbook"
description: "A step-by-step PHP patching playbook for teams responding to NCSC guidance on CVE-2026-109618 and CVE-2026-109619."
publishedAt: "2026-10-22"
author: "Bishu Studio Engineering Team"
category: "cybersecurity"
categoryName: "Cybersecurity"
readingTime: "5 min read"
tags:
  - "PHP Patching"
  - "CVE-2026-109618"
  - "CVE-2026-109619"
  - "Incident Readiness"
---

# A PHP Emergency Patching Playbook for Engineering Teams

The NCSC's October 2026 alert calls for prompt updates across PHP estates, not just the most obviously outdated hosts. For a team responsible for many applications, the hardest part is often knowing what runs where and proving the fixed code is live. Use this playbook to coordinate the response without confusing a successful build with a completed deployment.

## Key Takeaways

- Assign an owner and exposure level to each PHP deployment before work disappears into an untracked patch queue.
- Validate the PHP version running behind the web server after rollout, including long-lived workers and container replicas.
- Treat temporary mitigations as documented exceptions with owners and a deadline for permanent remediation.

## Build a Live PHP Inventory

Collect PHP versions from running servers, container images, platform settings, package managers, and vendor consoles. Map each result to an application owner, environment, public entry point, and business-critical workflow. A lockfile or build manifest alone does not tell you which runtime is handling requests today.

Prioritize internet-facing services and systems with sensitive data or privileged access. Do not discard newer versions from the inventory: the NCSC says organisations using any version of PHP should assess their exposure to both CVEs.

## Deploy a Fixed Release and Verify the Runtime

Consult the PHP project's current security advisory and your operating-system, hosting, or appliance vendor for the appropriate fixed release. If an application depends on an unsupported PHP branch, upgrade to a supported branch rather than relying on a generic version number copied from another distribution.

Build and test an updated image or package, deploy with a rollback plan, and recycle processes so no old workers keep serving traffic. Check the effective PHP version on each serving node or replica, then test sign-in, uploads, checkout, and other business-critical flows. Record the evidence of deployment alongside the asset and owner.

## Handle Exceptions Transparently

For deployments that cannot be upgraded immediately, review the PHP Foundation's published temporary mitigations and document exactly what was applied, where, and by whom. These measures buy time; they should not be presented as equivalent to a fixed release.

Escalate systems that cannot be patched or temporarily mitigated. The NCSC advises considering taking such systems offline. Keep the exception list visible until a verified fix is deployed, and preserve logs needed to assess any possible compromise.

## Implementation Checklist

- [ ] List runtime versions, owners, and exposure for all PHP deployments
- [ ] Identify supported fixed releases through PHP and vendor advisories
- [ ] Deploy updated packages or images and recycle serving processes
- [ ] Verify effective versions and smoke-test critical user flows
- [ ] Track exceptions, temporary mitigations, and incident-review evidence

## Sources

- [NCSC: Critical security issue affecting PHP](https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)