PHP Operators Need a Containment Decision
The emergency fixes are available. The urgent decision is now who will deploy them, who will restrict access if deployment slips, and who will verify recovery.
The maintainers’ updated advisory lists 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Install the appropriate fixed branch or a supplier-verified backport.
CVE-2026-109618 concerns failed allocation handling; CVE-2026-109619 concerns request data surviving its valid lifetime. Both allow unauthenticated code execution and retain the critical 9.2 rating.
Unpatched web-serving installations are at risk. The project highlights mod_php as highest risk, with a demonstrated attack before application code runs. That demonstration does not establish attacks in the wild.
Unsupported branches need vendor-backed fixes or migration. Minimal source backports are not renewed support. Configuration workarounds reduce only specific attack paths; updating is the complete remedy.
Where prompt deployment is impossible, consider public isolation. This remains a risk decision, not a blanket shutdown order.
Deploy, contain and verify
- Name an owner. Identify exposed applications, their runtime supplier and the person authorised to patch or restrict access.
- Agree the fallback. Decide which services can be isolated, what business functions will stop and who accepts that disruption.
- Require deployment evidence. Replace or restart existing workers, then confirm the running build against the published advisory. A downloaded package or hosting-provider promise is not proof of deployment.
- Validate recovery. Test essential transactions and inspect relevant logs before declaring normal service restored. Preserve suspicious evidence for investigation.
Ask managed-hosting suppliers for an explicit rollout and verification time. Do not assume an application update proves its underlying runtime has changed. Use the published guidance and recheck supplier coverage as packages roll out.
