Published
A website can have current WordPress software and still run on a PHP server that needs an emergency update. Here is how to find who owns that layer and ask for evidence.
Map the website layers to an owner
A maintenance relationship may cover page content without including the server software. Confirm who has authority to update each layer.
| Capability | Evidence to request | Suggested owner |
|---|---|---|
| Domain and DNS | Account owner, registrar, DNS provider, and emergency contact | Business owner, registrar, or IT provider |
| Website application | WordPress or other application, plugins, and update responsibility | Developer or marketing provider |
| PHP runtime | Running version or vendor package, update date, and confirmation that updated workers are serving requests | Hosting provider or server administrator |
| Web server and operating system | Patch responsibility, support status, and any documented exceptions | Hosting provider, cloud provider, or MSP |
| Monitoring and incident response | Available logs, file-integrity review, alert recipient, and who can isolate the site | Host, security provider, or named business contact |
The update your WordPress dashboard cannot install
Most business owners do not manage their website server. A marketing company designed the pages. A freelancer updates WordPress. A hosting company keeps the site online. An IT provider may manage the domain—but perhaps not the website.
That arrangement works until an emergency update belongs to a layer nobody clearly owns. On October 21, 2026, the PHP project released fixes for two critical vulnerabilities in PHP, the server-side software used by WordPress and many other websites.
Updating WordPress core, a theme, or a plugin does not install the PHP security release. A site can therefore be accurately described as “fully updated” at the application layer while its server runtime still needs attention.
What PHP fixed on October 21
The PHP project disclosed two critical issues in its core runtime: CVE-2026-109618, involving unsafe request state after an out-of-memory condition, and CVE-2026-109619, involving stale request state. Both can lead to remote code execution under affected conditions. NVD records a CVSS v4.0 score of 9.2 for each.
The upstream fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP’s advisories discuss web-facing SAPIs including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed. The affected conditions and exploitability depend on the runtime and configuration; the owner’s immediate task is to have the provider verify the actual installed package.
PHP 8.1 and earlier are outside the currently supported upstream release branches. PHP published minimal source backports for 7.4, 8.0, and 8.1, and some operating-system or long-term-support vendors may maintain their own fixes. An old version string alone cannot tell you whether such a backport is installed.
Why this matters to a small business
A business website may not host accounting or customer systems, but it can still support daily operations. Depending on what the server and hosting account can access, unauthorized server access could affect the site, information submitted through it, or connected services.
Potential consequences are reasons to verify the update—not evidence that a particular business was targeted or compromised.
- Changing published contact or payment instructions
- Redirecting visitors or adding a fraudulent form under a trusted business domain
- Accessing information retained by quote, support, employment, or document-submission features
- Disrupting sales, customer service, or time-sensitive business operations
- Affecting other sites that share the same hosting account
Visible, vulnerable, and compromised are different findings
Public checks can sometimes identify PHP, WordPress, or a version that a server chooses to advertise. A host may conceal that information, and some providers apply security fixes without changing the upstream version string.
A normal-looking homepage is not evidence that the server is patched. Conversely, a public PHP or WordPress signal is not proof that the installed package is vulnerable, exploitable, or compromised.
- Visible: public signals suggest the site uses PHP or PHP-based software. The exact server package may remain unknown.
- Needs verification: the host must confirm the running package and whether the applicable vendor fix is installed.
- Compromised: logs, files, accounts, server activity, or an authorized investigation provide evidence of unauthorized access.
The small-business website ownership gap
The practical problem may be less technical than contractual: each provider assumes another provider handles PHP. An invoice for “website maintenance” does not necessarily include operating-system or runtime patching.
- The marketing company maintains page content but not the hosting account.
- The IT provider manages Microsoft 365 and employee devices but not the website.
- The hosting plan provides updates only when the customer requests them.
- A former freelancer still controls the hosting login but no longer supports the business.
- An older site or vendor-operated customer, supplier, booking, or document portal remains online outside the current maintenance agreement.
A practical verification plan for business owners
You do not need to diagnose the vulnerability yourself. Assign the question to whoever can change the server package and ask for an answer tied to each public site.
- List public websites and portals: the primary domain, online stores, customer portals, quote and booking forms, upload sites, staging environments, old sites, and vendor-operated services carrying your business name.
- Identify who controls each hosting account and who can install or select the PHP runtime. This may be different from the person who edits the website.
- Ask for the running PHP version or vendor package, when it was updated, which vendor supplied the fix, and confirmation that the updated service or workers are serving requests.
- Ask the provider to identify any system that could not be updated and document the temporary access restriction, isolation decision, and permanent remediation owner.
- Ask what available logs and file-integrity evidence were reviewed for suspicious activity. A quiet homepage or lack of obvious changes is not a forensic investigation.
Copy this request to your website provider
Please confirm whether any website, portal, staging environment, or other public application associated with our company uses PHP. For each one, provide the running PHP version or vendor package, confirm whether the fixes for CVE-2026-109618 and CVE-2026-109619 are installed, and identify the evidence supporting that answer. If a system cannot be updated, please state what access restriction or temporary isolation is in place and what is required for permanent remediation. Please also confirm what logs or file-integrity evidence have been reviewed for suspicious activity.
This request gives a developer, hosting provider, or IT provider a specific task without asking the business owner to interpret server configuration.
Document who owns the next update
After the emergency update, record who owns each website layer and who receives urgent vendor notices. Decide who can authorize an emergency change or take the site offline, where administrative credentials are held, and what happens when a developer or marketing relationship ends. That record prevents an urgent notice from circulating among providers while no one owns the fix.
What a public review can—and cannot—verify
The free Zero-Access Business Exposure Review uses public signals. It may identify website or technology signals worth asking a provider about, but it cannot verify which server package is installed or whether it was updated. A hidden version is unknown—not evidence that the site is safe.
When the question is whether internal safeguards are actually in place, the $1,995 Business Security Baseline is responsible for agreed internal safeguard verification. Neither public visibility nor a version banner establishes exploitability or compromise.
Frequently asked questions
Is PHP the same thing as WordPress?
No. WordPress is an application written in PHP. The server’s PHP runtime executes WordPress and is maintained separately.
Can the WordPress dashboard install these PHP fixes?
Usually not. The hosting provider or server administrator updates the PHP runtime. Some managed hosts do this automatically; others require a request or a version change in the hosting control panel.
How can I find the PHP version my website uses?
Ask the hosting provider or check the hosting control panel. Public technology checks may identify PHP without reliably revealing the exact installed package or patch state.
Does a web application firewall replace the PHP update?
No. A firewall may add a mitigation layer, but PHP and security authorities advise updating to a fixed release or verified vendor package. Cloudflare also recommends patching even where its WAF protections are in place.
Should I take my business website offline?
Not automatically. Ask the provider to verify the running package promptly. If an affected system cannot be updated, have its technical owner assess temporary isolation or restricted access based on the application’s role and business impact.
Does an older PHP banner prove that someone accessed my website?
No. It is a public indicator that needs provider verification. Evidence of compromise requires separate review of logs, files, accounts, server activity, or other investigative findings.
Sources and further guidance
The technical status and recommended fixed releases in this guide were checked against PHP’s advisories and release information, NVD, and CERT-EU on October 21, 2026. Follow the instructions for the exact hosting or operating-system package; vendor guidance can differ.
Start with the right level of evidence.
The free Zero-Access Business Exposure Review checks public signals only; it cannot verify an installed server patch. The $1,995 Business Security Baseline is responsible for agreed internal safeguard verification.