When a component publishes a critical advisory, our customers don't experience it as a CVE number. They experience it as a question about systems they trust to be running: does this touch me? As the integration partner for those systems, our job is to turn the upstream text into a documented answer quickly, and to change nothing about a business system on the way.

This week's answer concerns the PHP project's security releases of October 21, 2026: two fixes for critical, remotely exploitable weaknesses in PHP's core request lifecycle, which serves everything from web applications to integration endpoints.

Inventory every host for a PHP runtime. A meaningful share of integration servers run none at all: database replication, analytics, batch stores. Each gets a one-line documented disposition the same day.

Map the serving recipe of every web host. The version number matters less than the recipe. The confirmed attack paths in this advisory depend on specific deployment shapes, and the recipe answers reachability in minutes.

Match branches to fixed releases. For this advisory: 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with minimal source backports promised for end-of-life branches. Where a distribution channel has not published its build yet, that is a statement of fact, recorded as such.

Search application code for the named mechanisms. Whether a feature is exploitable and whether it is even used are different questions; a code search answers the second one definitively. Here the searches come back empty by construction rather than by luck: our standing rule is that solutions never use server-side session variables, in any language. State lives in engineered stores, and any application node can serve any request while sharing nothing server-side.

Harden what is behavior-neutral. Unused core features go off administratively at the server level. Body-size caps align with the stricter limits the web layer already enforces. Nothing user-visible changes.

Schedule the rest. Package upgrades join the next routine maintenance window inside the phased runbook, with service-by-service verification, and database replication health checked before anything resumes.

Write the audit log as the work happens. Intent before action, verification after, nothing backfilled. Every claim in the customer letter maps to a timestamped line the customer can be shown.

What the first pass found this week. Several integrated systems carry no PHP at all and were dispositioned in minutes. The web-facing systems required the actual reading, and the outcome hinged on recipe: stacks that serve applications through isolated worker processes behind a front server, with the affected mechanisms unused and now disabled administratively, do not present the conditions the advisory documents. That is what we mean by structural safety: the exposure was answered by how the system was built, before this week's patching question even arrived.

The sweep is proceeding across all client servers as a precaution, including hosts the first pass already cleared, because an audit that skips anything is not an audit.

The version reality, stated plainly. Branches past their support dates receive minimal, source-level fixes, and distribution channels publish on their own cadence. We will not turn that into emergency downtime for a customer. Upgrades join scheduled windows, in runbooks the client already knows, announced in advance. The honest version of security communication is what we did, what we deliberately deferred, and why.

A solution is a promise about other people's systems. Advisories are how we audit that promise, and the audit log is how we prove it was kept.