# A Patched Vulnerability Still Exposes Whoever Has Not Updated ## Claim A fast vendor patch measures the maintainer's response, not the ecosystem's real exposure — exposure is set by how many installs have actually applied the fix, so a security story that reports time-to-patch without time-to-adoption is measuring the wrong variable. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Applies specifically to the adoption-lag window on a branch that already has a working patch available — distinct from a maintainer being structurally unable to patch old, unsupported branches at all. - Strongest for plugins without forced or default auto-updates, where applying a security release is a discretionary action an admin has to take. - The five-day fix in this case is a genuinely good maintainer response; the claim isn't that vendors are slow, it's that vendor speed and ecosystem exposure are two different numbers that get conflated in security reporting. - Breaks down where auto-update is the default and near-universal, collapsing the adoption gap this claim depends on. ## Evidence > [!quote] ID:rw_01m1kdhxvttzxmtj2r9k4pndp1 > "Since the vendor fixed the issue, only approximately 35% of the plugin's user base has updated to the latest version, with the remaining 3.25 million sites running a vulnerable release of All-in-One WP Migration and Backup." ServMask was notified of CVE-2026-19949 on 2026-08-15 and shipped a fix in version 7.110 five days later, on 2026-08-20 — a fast turnaround. Two weeks after that fix, Wordfence reports only about 35% of the plugin's 5M+ install base had updated, leaving roughly 3.25 million sites still running the vulnerable version. The vendor's part of the timeline is complete; the ecosystem's exposure timeline has barely started. ## Links - [[3. Resources/Permanent Notes/Patch Coverage Is a Distribution Problem Not a Code Problem]] — contrasts: that note is about installs a patch structurally cannot reach (old, unsupported branches with no backport); this note is about installs the patch has already reached and simply haven't applied it — different mechanism, same downstream effect of measured exposure outliving the fix - [[3. Resources/Permanent Notes/A Patch Release Starts an Exploitation Race Not a Grace Period]] — sharpens the stakes: the exploitation-race clock that note describes runs the entire two weeks (and beyond) that this note's 65% of installs remain unpatched - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — direct home: adoption-rate tracking, not just patch-speed tracking, as a hosting-stack and ecosystem security metric ## Tests / falsifiers - Pull the wp.org install-base chart for this plugin at 30 and 60 days post-patch; if adoption converges toward 90%+ within a month, the "exposure lives in adoption" framing needs a time bound rather than reading as open-ended. - Compare this plugin's adoption curve against a plugin with forced auto-updates enabled by default for security releases — a materially faster curve there would support treating auto-update policy as the lever that actually controls this claim's real-world size. ## Source - [[3. Resources/Readwise/Articles/WordPress Backup Plugin Flaw Exposes Millions of Sites to Takeover Attacks]] — BleepingComputer relay of Wordfence's advisory; the 35% figure comes from wp.org's install-base chart via Wordfence and is not independently verified from a machine-readable source in this capture.