On September 25, the Cybersecurity and Infrastructure Security Agency added a WordPress Core vulnerability to its Known Exploited Vulnerabilities catalog.

The vulnerability, CVE-2026-87902, can let an unauthenticated attacker include a local PHP file outside the active theme directories. Under certain server and theme configurations, that can lead to remote code execution.

WordPress fixed it in version 7.1.2 and backported the repair to every branch from 4.7 forward. CISA still required federal agencies to perform forensic triage, not merely install the update.

The technical details will not apply to every WordPress site. The operational question applies to every firm with a website:

Who is responsible for knowing whether the site is affected?

The website often falls between vendors

A law firm or CPA firm may have an IT provider managing computers, Microsoft 365, security tools, and backups. A marketing agency designed the website. A separate hosting company runs the server. The domain may be registered under an employee’s personal account or an old vendor’s name.

When the site needs a security update, each company can reasonably assume another company owns it.

The marketing agency may handle content but not server maintenance. The host may keep the operating system running without updating WordPress, its themes, or its plugins. The IT provider may protect the firm’s internal network without having administrative access to the website.

None of those arrangements is necessarily wrong. The problem is leaving the responsibilities unstated.

The firm’s website is not a static brochure. It is software exposed to the internet all day. It may accept contact forms, job applications, newsletter signups, document uploads, or online payments. Even a simple site uses a content-management system, hosting environment, domain registrar, DNS provider, certificates, themes, and plugins.

Someone needs to own each part.

“Managed hosting” can mean several things

The words “managed WordPress hosting” sound comprehensive. The service may include automatic WordPress Core updates while leaving plugin compatibility to the customer. It may back up the site but retain only a few days of copies. It may scan for known malware without investigating suspicious administrator activity.

A website proposal that says “maintenance included” may refer to editing pages and fixing broken layouts rather than security maintenance.

Ask the vendor to describe the service in plain terms:

Who installs WordPress Core, theme, and plugin security updates?
How quickly are critical updates installed?
Does anyone confirm that automatic updates succeeded?
Who reviews administrator accounts and login activity?
How often is the site backed up, and has anyone tested a restore?
What security monitoring runs on the site and hosting account?
Who investigates if a vulnerability was exploited before it was patched?
How quickly will the firm and its IT provider be notified of an incident?

The answers should identify a company or person, not “the system.”

A successful update does not answer what happened before it

CISA’s response to this WordPress vulnerability included forensic triage because active exploitation had already been observed. Installing the fix closes the known opening. It does not show whether an attacker used that opening while the site was vulnerable.

That is the same distinction we covered in When Patching the Firewall Is Not Enough. Remediation and investigation are separate jobs.

For a website, an investigation may include reviewing administrator logins, recently created accounts, modified files, scheduled tasks, redirects, DNS changes, and traffic during the exposure window. The exact work depends on the hosting setup and available logs.

This is another reason to settle ownership before an incident. A vendor cannot review logs it never collected. A firm cannot preserve evidence if nobody knows which provider holds it or how long that provider keeps it.

Know who controls the accounts

Maintenance responsibility is only part of the website problem. The firm should also know who owns the domain registration, hosting account, DNS, analytics, and content-management administrator credentials.

Those accounts should belong to the firm, even when a vendor manages them. Use firm-controlled email addresses, individual administrator accounts, and multifactor authentication. Avoid a shared password known by several employees and outside contractors.

The firm should be able to remove a former vendor without losing the domain or rebuilding access from scratch. It should also have a documented way to regain control if the person who set up the site is unavailable.

An inventory can be short. Record the provider, account owner, administrative users, renewal date, billing contact, recovery method, and the person responsible for each security task. Review it when vendors or employees change.

Connect the website to the incident plan

A compromised website may not touch the firm’s internal network, but it can still create a business problem. Attackers can alter pages, redirect visitors, imitate the firm’s payment instructions, or use the firm’s domain and reputation to make a malicious page look credible.

The website should appear in the firm’s incident-response contacts. The marketing provider, host, domain registrar, and IT provider need a way to reach one another. The firm should decide who can authorize taking the site offline, restoring a backup, resetting administrative access, or warning clients.

Contact forms deserve specific attention. Determine what data they collect, where submissions go, how long copies remain on the website, and who can access them. A form should not quietly become a second client-information system that nobody monitors.

Ask for evidence, not reassurance

Start with the current WordPress issue. Ask the website vendor which WordPress version is installed, whether the site met the affected conditions, when it was patched, and whether available logs were reviewed for signs of exploitation.

Then broaden the conversation. Request the last successful backup date, the date of the most recent restore test, a list of administrative users, and the written division of maintenance responsibilities.

If three vendors each say the website belongs to someone else, the firm has found the problem before an attacker did.

If your website sits outside your normal IT and security process, Artech can help document the ownership, access, backup, and incident-response gaps.