- Ask for evidence that the PHP runtime serving your website was updated, not just its CMS or plugins.
- PHP's October 23 follow-up needs a separate configuration review; the October 21 update is not the whole checklist.
- Give unresolved sites an owner, a temporary exposure decision, and a deadline.
Start with the website that takes orders
If your website takes bookings, sells products, or collects customer documents, ask its operator about PHP today. You do not need to know how the application was written to ask who maintains the runtime underneath it.
PHP's October 2026 announcements, checked October 23, identify fixes for CVE-2026-109618 and CVE-2026-109619 in versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12. The October 21 advisory covers installations serving web requests, including PHP-FPM and Apache configurations.
On October 23, PHP also advised disabling session.upload_progress.enabled pending a regular bugfix release for an unusual session-serialization configuration associated with CVE-2026-115560. Its advisory explains the conditions and notes that applications which never change the serialize handler at runtime can keep the feature enabled. Ask the operator to check that guidance separately.
Those are vendor findings. The response plan below is our recommendation for a small business, not evidence that your own site has been attacked.
Send your host a question they can answer precisely
A hosting dashboard that says WordPress is current does not establish which PHP process is serving requests. A developer may maintain the application while a different company controls the server. Find both owners before assuming either has finished.
Send a request with these details:
- The production domains and applications you need checked.
- Whether PHP runs there, including old subdomains, staging sites, and scheduled jobs.
- The running PHP version and package build, or the vendor advisory confirming an equivalent backported fix.
- When the updated processes were brought into service.
- Whether the October 23 configuration guidance applies and what action was taken.
- Any remaining exception, its owner, and its next review time.
Do not accept a general statement that the platform patches automatically as the entire answer. Ask for the deployment result for your account or service. A managed host may not expose process details to customers; an account-specific confirmation and a dated vendor advisory are reasonable alternatives.
Make the change without losing the business workflow
For a hypothetical booking website, the acceptance test is not just that the home page loads. Someone should submit a test booking, receive the expected notification, and check that the appointment appears in the back office. If the site takes payment, use the provider's approved test method rather than a real customer's transaction.
Agree the test before the change. Name the person who can approve a brief interruption and the person who will check the result. Keep an export or backup appropriate to the application, but do not confuse having a backup with knowing that it can be restored.
Ask the operator to cover every serving instance. A command-line version check on one machine is not evidence about a separate web pool or a container still running an older image. For teams managing their own servers, PHP's FPM configuration reference documents pool-level settings. That is one reason a global configuration edit needs verification against the affected pool.
Keep configuration dumps and diagnostic pages private. There is no need to publish a phpinfo page on the internet to prove to a customer that an update happened.
If the site cannot be patched today
A legacy plugin or abandoned application can turn a routine update into a business decision. Ask the maintainer to explain the specific incompatibility and the shortest route to a supported deployment. Consult PHP's supported-version schedule when deciding whether this is a temporary patch problem or a replacement project.
The owner should choose among tested temporary restrictions, a reduced service, or taking the affected function offline. For example, a business might temporarily route booking requests to an existing phone channel while its provider repairs the website. That is a continuity choice, not a claim that every PHP vulnerability is blocked by removing one feature.
Do not copy emergency memory or upload settings from social media without the operator reviewing their effect. A workaround that exhausts server memory can replace a security problem with an outage. Record temporary changes so they do not become undocumented permanent settings.
Check for trouble without declaring a breach
Ask the operator whether there were unexplained worker crashes, unexpected application changes, new administrator accounts, or unusual outbound activity during the exposure period. These are investigation leads, not proof of exploitation. An absence of obvious errors is not proof that nothing happened either.
If there are credible signs of compromise, preserve relevant logs and involve the incident owner before routine cleanup destroys useful evidence. Patching closes a vulnerability; it does not establish that an earlier intrusion has been removed.
The business update can be short: which sites were covered, when the running service changed, whether the booking or checkout test passed, and what remains unresolved. Use the vulnerability prioritization worksheet to track the exceptions. Close the task when the serving application and its business workflow have been checked, not when an update email arrives.
Turn this response guidance into clearer roles, containment decisions, evidence paths, and executive briefing rhythm.