- The advisory must name the version that fixes it, WordPress must be offering an update that reaches it, and the offered version must fall outside the advisory’s own affected range. “Merely newer” is not evidence that this vulnerability is closed — a feed that writes
1.0-1.6,<0.9for one slug derives a fixed version of 0.9, and installing 1.5 on that basis would land back inside the 1.0–1.6 window while the audit row claimed the opposite. - A candidate whose range cannot be parsed is refused: "we could not check" must not read as "we checked". A record whose range is
*is therefore never patched. - The operator's allow list, when written, is the whole world; the deny list beats it. The plugin that runs the checkout is a reasonable thing to deny.
- Never on a staging copy. Never on a plugin directory that is a symbolic link — that is somebody's working checkout, and an upgrade would replace it with a zip.
- A failure is remembered for 24 hours, so a plugin whose zip 404s is not re-downloaded on every tick.
- Cron only. A multi-second download and a filesystem swap inside a page request would sit in front of a visitor, and that request might be the attack.
- Plugins only. Core and themes are out of scope today.
- The e-mail and the screen name both versions — the one that was inside the range, and the one that is not.
- The cron event schedules itself from the class constructor rather than from the activation hook: WordPress does not run activation hooks on an update, so a schedule registered there exists on fresh installs and nowhere else. It is scheduled whether or not the rule is switched on, because an operator who enables it six months later must not need a re-activation for it to work.