SecurityWeek reported on September 24, 2026, that attackers are actively exploiting CVE-2026-87902, a critical WordPress core vulnerability tied to page-template resolution. WordPress patched the issue in version 7.1.2 and backported fixes to older branches, while Patchstack reported that probing quickly moved into attempts to write PHP files to disk on vulnerable sites.
The technical details matter to the people managing the site. The business decision matters to the owner. If your company depends on a WordPress website for leads, appointments, donations, patient forms, school updates, or customer trust, the answer cannot stop at "updates are automatic."
Why this matters beyond one patch
Many smaller organizations do not treat their public website like part of the business technology stack. It may sit with a web designer, a marketing agency, a hosting company, an MSP, an internal administrator, or some mixture of all four. That shared ownership works until a critical WordPress vulnerability turns patching into a question of evidence.
According to the WordPress advisory, the flaw can lead to conditional remote code execution when certain theme and server conditions are present. That does not mean every WordPress site is compromised. It does mean owners should know who checked the site, what version is running, whether affected themes or PHP conditions apply, and whether logs show suspicious activity after the public disclosure.
For a New Jersey business owner, the practical issue is not memorizing CVE-2026-87902. It is making sure the company can prove that business website vulnerability checks are actually happening when the risk is current.
The business decision is proof, not panic
Website patching is often described as routine maintenance, and most of the time it is. But active exploitation changes the conversation. The owner-level decision is whether to accept a general assurance or require a short written record.
That record does not need to be a novel. It should say the WordPress branch and patched version, whether auto-update completed successfully, which themes are active, whether the known preconditions were reviewed, whether any web application firewall or host rule was applied, and whether logs were checked for exploitation attempts.
This is where managed hosting and web vendor accountability meet. If one provider hosts the site, another maintains the theme, and another watches security, someone still needs to own the answer. Otherwise the website becomes a very public system with very private confusion behind it.
Questions to ask your web vendor, MSP, or host
- What WordPress version is the site running now? Ask for the exact version or patched branch, not a general statement that updates are enabled.
- Was CVE-2026-87902 specifically reviewed? Confirm that the team checked this vulnerability rather than only running a normal monthly update process.
- Do our active themes match any known risk conditions? The advisory calls out theme directory patterns and PHP/server preconditions that should be checked.
- Were logs reviewed after disclosure? If attackers were already probing sites, the question is not only whether the patch is installed, but whether anyone looked for suspicious requests.
- Who owns emergency website patching? Clarify whether the host, web agency, MSP, or internal staff has authority to patch, test, and escalate.
- What happens if the site breaks after a security update? The answer should include backups, rollback steps, testing, and who approves a temporary mitigation.
A practical next step
Pick the WordPress sites that matter to revenue, scheduling, reputation, or customer communication and ask for a one-page patch evidence note. Include the site URL, current WordPress version, update time, active theme, relevant plugin or theme checks, log-review result, and the person or vendor accountable for follow-up.
If the answer comes back as "we think it is fine," keep asking. Patch evidence is the receipt for a security promise. It is also the difference between a calm owner review and a scramble after a customer, employee, or search engine notices something wrong first.
Sources and further reading
