The Morning-After Habit: Two Disciplines That Close the Exploit Window

Last updated: September 28, 2026.

The patch for CVE-2026-87902 shipped on September 22. The first exploit attempt landed at 11:49 UTC the same day. Your update process is now a race, whether you signed up for it or not.

On September 22, 2026, WordPress shipped version 7.1.2, a security-only release fixing CVE-2026-87902, rated Critical at 9.2 out of 10 (WordPress GHSA-7hp8-65ch-5whp; The Hacker News, Sep 22, 2026). The flaw affects every version from 4.7.0 through 7.1.1 — nearly a decade of releases — with fixes in 7.1.2 and backported releases on every supported branch down to 4.7.37 (WordPress, Sep 22, 2026). Security firm Patchstack blocked the first exploitation attempt at 11:49 UTC the same day. Within a day, attack traffic had surged more than tenfold, and payloads had escalated from harmless probing to writing PHP files onto servers through pearcmd.php (TechTimes, Sep 25, 2026). CISA confirmed active exploitation on September 25 and set a federal patch deadline of September 28 (HOL Guard, Sep 25, 2026).

Five days earlier, WordPress had already shipped a security release, 7.1.1. Shop owners who updated on September 17 and felt safe needed a second emergency update on September 22 for a completely separate flaw. That is the new normal this post is about — and it is why two boring habits, update discipline and scanning discipline, now decide whether your shop survives a disclosure week.

The window you used to have is gone

For more than a decade, site owners had an unspoken grace period: a vulnerability was disclosed, and weaponized attacks arrived days or weeks later. That grace period has collapsed. Mandiant's M-Trends 2026 puts mean time-to-exploit at roughly minus seven days — on average, exploitation begins before disclosure, a figure driven by nation-state zero-day campaigns (via SuzuLabs; Brandefense, 2026). For disclosed flaws the squeeze is just as real: Rapid7's 2026 report finds the median time from disclosure to CISA KEV listing compressed from 8.5 to 5.0 days, with exploited high-severity flaws more than doubling year over year, from 71 to 146 (via CSA, Apr 2026). Fortinet's 2026 report finds the window for critical outbreaks down to 24–48 hours, from 4.76 days a year earlier (Fortinet Global Threat Landscape Report 2026).

Two different races hide inside those numbers. In the post-patch race — this month's WordPress case — attackers diff the published fix, isolate the vulnerable code path, and build a working exploit within hours; your update speed is the defense. In the pre-patch race — a true zero-day — exploitation starts before any fix exists, and no update discipline can save you; only detection, tested backups, and least-privilege containment limit the damage. This post is about winning the first race, and surviving the second.

Defenders did not keep pace. For edge devices such as VPNs and firewalls, organizations took a median of 32 days to fully remediate exploited flaws, with only about half remediated through the year (Verizon DBIR 2025). Every day between patch release and your update is a day attackers already own the exploit for.

Why shops keep losing this race

A June 2026 Censys scan of the public web — when the latest release was 7.0 — found that only 14 percent of visible WordPress sites ran the latest patch. Counting sites on the previous, already-discontinued version only reaches about a third (secure.com, Jul 8, 2026; Cybernews, Jul 2, 2026). The plugin layer is no better: Yoast, installed on over five million sites, was current on just 22 percent of them. Underneath it all, more than 70 percent of sites ran outdated PHP, with over 20 percent still on PHP 7.4, deprecated since November 2022. Censys linked at least 900 defaced sites to the "Hacked By MR.GREEN" campaign targeting outdated installs.

The reasons are human, not technical. Updates break things, so owners delay them. Censys itself notes that auto-updates can cause compatibility headaches, which is exactly why admins turn them off (secure.com, Jul 8, 2026). Forgotten installs — old marketing microsites, staging copies, agency-built sites nobody adopted — quietly run old versions outside any update channel. And most shops scan never: no baseline, no schedule, so drift goes unnoticed until a breach notice arrives.

None of this requires a sophisticated adversary. Automated scanners probe the entire internet within a day of disclosure. Being small does not hide you; scanners do not check revenue before probing.

Discipline one: the morning-after update check

Automatic updates are the right default — the shops that sailed through the September 22 release with no action were the ones whose background updates moved them overnight. But "automatic" is not "verified." Auto-updates miss installs where the feature is disabled, overridden by a host, or pointed at the wrong branch (TechTimes, Sep 25, 2026).

The 60-second check, the morning after any security announcement:

1. Open your WordPress dashboard and read the version number at the bottom. For this flaw, anything from 4.7.0 through 7.1.1 is vulnerable; the fix is 7.1.2, or the backported release for your branch (7.0.6, 6.9.9, 6.8.10, down through 4.7.37). The ground truth is the number, not the feeling that "we updated recently."
2. Confirm automatic updates are enabled for minor and security releases, under Dashboard, Updates. If your host manages updates, confirm with them directly — "the host handles it" is a claim worth one email a year.

The once-a-year exposure check — not 60 seconds, but do it once and revisit yearly:

1. Ask your developer or host three questions: does our active theme carry a top-level folder starting with page-? Is there a readable local PHP file on the server attackers could reach — in this campaign, the PEAR front end pearcmd.php? And does our PHP run with register_argc_argv turned on? All three lining up put a site in the directly-exploitable group for flaws like CVE-2026-87902 (Patchstack, Sep 22, 2026; The Hacker News, Sep 24, 2026). Turning that PHP setting off for web requests, or removing unused PEAR components, blocks the known route — but neither repairs the underlying flaw. Only the update does that.
2. After any significant change — new plugin, theme switch, host migration — check that the next scheduled scan covers the changed surface, not just the homepage.

If your site sat unpatched at any point after September 22, patching now is necessary but not sufficient: exploitation predates most people's patching. Search server logs from September 22 onward for pagename values containing %2e%2e or %252e%252e and requests referencing pearcmd, and check /tmp and /var/tmp for PHP files, which have no legitimate reason to be there on a web server (Patchstack, Sep 22, 2026). A successful write is a compromise — handle it as an incident, not an update.

One honest caveat: not every unpatched site gets compromised — most probes bounce off sites missing one of the three preconditions. But you cannot tell which side yours is on without checking, and automated scanners probe indiscriminately. Assume exposure until the version number and the checks say otherwise.

Critical releases go same-day, as fast as you can verify them on staging. Routine updates: check at least monthly, and never let anything sit unreviewed longer than three months (Censys recommends a one-to-three-month rhythm, Jul 2026). The habit that matters is verification: glance at the version number the morning after every security announcement, and make the next disclosure boring.

Discipline two: scan on a schedule, plus after every change

A scan is how you learn what your update discipline missed — the forgotten subdomain, the plugin someone installed and forgot, the certificate expiring next week. Frequency should match risk:

• If you take payments or hold customer accounts, scan daily.
• For a standard small business site, weekly automated scanning is the minimum defensible cadence.
• After every deployment, plugin update, or server change, trigger an extra on-demand scan. Event-driven scans catch misconfigurations at the moment they are introduced, before production traffic finds them (Sensagraph, 2026; ShieldReport, 2026).
• Quarterly, have a human look at what automation cannot see: business-logic flaws and chained attack paths that scanners consistently miss.

Two rules make scanning real instead of theater. First, findings must go somewhere with an owner and a deadline — critical within a day, high within a week — not into an inbox nobody opens. Second, track the trend: recurring findings mean the patching process is broken; a spike after a deployment means pre-release checks need work. Scanning without remediation is just a more detailed way of being vulnerable.

One adjacent habit, because breaches keep proving it: test that your backup restores. More than 90 percent of organizations say they have backups, yet about a third fail to recover when ransomware strikes, and over half test their recovery plan once a year or less (Kaseya, 2026). An untested backup is a hope, not a plan.

Key numbers

• 11:49 UTC, September 22: first blocked exploit attempt for CVE-2026-87902, the same day as the patch (Patchstack, via TechTimes).
• 350,000+: WordPress instances still running vulnerable versions (Shadowserver, via TechTimes, Sep 25, 2026).
• 30,813: unique IP addresses observed sending matching exploit requests, September 23–28 (CrowdSec, Sep 28, 2026).
• 14%: WordPress sites on the latest patch in June 2026, when the latest release was 7.0; ~31% on actively maintained versions (Censys, Jul 2026).
• 24–48 hours: Fortinet's window for critical outbreaks, down from 4.76 days (Fortinet Global Threat Landscape Report 2026).
• 32 days: median time to fully remediate exploited edge-device flaws (Verizon DBIR 2025).

Final takeaway

Attackers now arrive in hours; most shops still patch in weeks. You cannot change attacker speed, but you control the two variables on your side: how fast verified updates land, and how quickly scans surface what updates missed. Enable auto-updates, check the version number the morning after, scan weekly at minimum and after every change, and route every finding to an owner with a deadline. Five minutes of discipline, practiced every time, beats a panic weekend once a year.

Is your site ready? Run a free security scan — 40+ automated checks, instant results, no commitment.