Your host says it patched PHP. What would confirm that?

Imagine you look after a handful of client websites. Your host sends the message you wanted: PHP has been patched. You file the ticket, open the sites, and everything loads. By lunchtime, another client asks whether their site was included.

The useful answer is a record tied to the PHP runtime serving that site: which installation was updated, what fixed build or vendor package it’s running, and whether the workers handling requests were replaced. A working homepage and a reassuring ticket leave those questions open.

Why this needs attention now

PHP’s October 21 security advisory identifies two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, and urges immediate updates. Its fixed upstream releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Web-serving installations are in scope; mod_php carries the highest stated risk. The notice also allows for vendor backports, so an older-looking version needs its vendor’s exact package advisory checked.

If you operate an affected installation, follow the current PHP and provider guidance promptly. Don’t wait for a new tool or a polished spreadsheet before arranging the update. If someone else manages the server, send them the advisory and ask what’s running for your account.

Ask for the site’s runtime, then follow the evidence

A useful provider reply should identify the site or account, its serving runtime and full package revision, the advisory that establishes the fix, and when the running workers were restarted or replaced. If a service has several pools or replicas, ask how the reply covers them. Keep the time of the observation beside the evidence; a result from before a deployment can’t settle what’s running afterward.

There’s a free starting point. OpenAI’s PHP2Shell checker repository includes a URL checker and a server-access skill. The URL tool reads advertised headers and reports unknown when the version is hidden; headers can be changed. The server guidance asks you to match PHP to the installation serving the site and check vendor revisions. These are useful distinctions to keep when an assistant turns a check into a summary. We haven’t run either tool against a live host for this article.

For the hypothetical client above, I’d keep a small evidence row for each declared target. The row needs the asset owner, pool or replica, observed running build, applicable fix reference, worker replacement time and an evidence pointer. Leave the row unresolved when any consequential link is missing. A provider’s statement can be recorded honestly as a provider statement while you wait for stronger evidence.

When one patch ticket turns into a fleet

One site can fit in a ticket. Several clients, hosting accounts and PHP pools are where “we patched it” starts to lose its meaning. The useful question becomes: which targets still need an answer, and who needs to provide it?

That is the job we built PHP Fleet Patch Ledger for. Give your agent a structured inventory and the evidence you have collected. The helper returns a per-target JSON ledger, while the agent can turn the unresolved rows into a follow-up table and a provider request for you to review. It does not discover your servers, install patches or authenticate a provider’s evidence.

In our synthetic two-pool example, one pool has the required patch evidence recorded. The other stays at NEEDS_EVIDENCE because its serving-runtime and timing evidence are missing. That distinction is the point: a reassuring answer for one pool must not silently clear another.

The skill is a $12 one-time Agensi purchase, intended for an agent that can retrieve the complete supporting files and run Python 3.10+ in memory. It is not a standalone hosted scanner. For one or two sites, the free worksheet above may be enough. For a fleet, the ledger gives the follow-up work a consistent structure.

Keep the jobs separate: use the current PHP and hosting-provider guidance to arrange the patch, collect evidence for the runtime actually serving each target, and use the ledger to keep unanswered questions visible. A completed evidence row is not a security clearance.

Check the application after the change, too

Once the runtime evidence is in hand, check the application journeys that matter for that site. A members’ login, a file upload and a queued background job can fail in different ways. Choose the actual journeys rather than copying a universal test list, and use authorized test accounts and sandbox transactions.

Keep those results alongside the patch record without merging their conclusions. A successful login tells you about that login on that environment and build. It doesn’t establish the PHP fix. Equally, a confirmed fixed runtime doesn’t show that every application path still works. If a regression appears, work through it with the operator rather than automatically rolling back to a known affected runtime.

Give the evidence a useful ending

The agency’s job gets easier when each client has a named owner and a next action: confirmed within the recorded scope, awaiting a provider answer, or needing an update. Keep unresolved targets in view, including sites that were absent from the original inventory. An assistant can organize those answers, but someone still has to establish that the inventory is complete and the evidence belongs to the running service.

For today, open the host ticket again and ask which runtime and which targets it actually covers. Keep the answer somewhere the next person can find it. That’s a much better handoff than trying to reconstruct “we patched it” after everyone’s moved on.

Practical scope: this article hasn’t assessed your infrastructure or established whether an incident occurred. Patch evidence, application regression results and compromise assessment answer different questions. Follow your operator’s incident process if there’s reason to suspect exposure or compromise.