A version published under your stolen registry credential is already installed downstream — how do you reach those installers?

## The uncomfortable starting point Publishing is a one-way broadcast. You know how many times a version was downloaded and roughly from where; you do not know who runs it, in what product, or whether they even know the dependency exists — most consumers pulled it transitively and have never heard your project's name. Revocation and distrust are only half of the response; the other half is notification, and notification against an unenumerable audience is a reach problem, not a writing problem. ## Rank channels by what they reach **Machine channels (high reach, low effort for the consumer).** Every mainstream ecosystem has an advisory database, and the entries are consumed automatically: scanners match installed versions against affected ranges, update bots open pull requests, and platform dashboards light up. An entry keyed to the package name and the affected version range is the single highest-leverage notification you can produce, because it arrives inside the consumer's existing workflow, at the moment they build, without them having subscribed to anything. Ecosystem advisory feeds are also aggregated into cross-ecosystem formats, so one accurate entry travels further than a dozen posts. Authoring the advisory document itself — identifier assignment, wording, severity — is a separate discipline; what matters here is that the entry exists and that the affected range is right. **Install-time metadata (medium reach).** Registries generally provide a way to mark a version as unwanted without deleting it — deprecation, yanking, or an equivalent flag. Semantics differ, but the shape is consistent: the version stays resolvable for anyone who already pinned it, so you do not break existing builds, while new resolutions skip it and the client prints a warning. That warning lands in front of an engineer who is actively working, which beats an email nobody opened. Deleting outright is the aggressive alternative and it costs you: it breaks reproducibility for everyone who pinned it, and it destroys the artifact your consumers need in order to hash and inspect what they actually ran. **Human channels (low reach, high narrative value).** The project page, the release notes, an announce list, a status page, social posts. These reach people already paying attention, which after a compromise is a small and self-selected group. They are still worth doing, for three reasons: they carry the timeline and the honest account that machine channels cannot; journalists, aggregators and downstream packagers read them and re-broadcast; and consumers who discover the problem late need a canonical page to land on months from now. **Direct contact (tiny reach, disproportionate value).** You usually know a handful of large consumers — enterprise users, distro packagers, platform vendors who repackage you. Each of those is a multiplier: a distribution maintainer who acts reaches every one of their users. ## Give them a destination A notice that says "stop using version X" without saying what to use instead produces pinning, forking and inaction. Publish a clean higher version first, from content you rebuilt and control, so the machine channels have an upgrade target and the bot's pull request is mergeable. If the fix requires a major-version jump or a namespace change, say so explicitly, because automation will not cross that boundary by itself and those consumers need a human decision. ## Use download counts for sizing, not targeting Counts tell you order of magnitude: whether this is dozens of installs or millions, whether it went out to mirrors, whether pulls continued after you acted. Continued pulls after the advisory is the useful signal — it usually means caches, mirrors, vendored copies or air-gapped consumers, and it tells you the notification has not converged. What counts never tell you is identity, so any plan that begins "we will email the affected users" is built on something you do not have. ## Say it early and revise Waiting for a complete root cause before saying anything maximises the number of people who install the bad version in the meantime. Publish what you know, mark it as preliminary, give the affected range as your best current estimate, and update. If the range later widens, a second notification is cheap; a month of silent exposure is not.