The security contact that anyone can buy

A dead security contact is usually filed under "untidy." A reporter emails security@project.dev, the mail bounces, they shrug and open a public issue instead. Annoying, not dangerous.

That framing is wrong when the domain does not exist. A bounce is a failure that both sides can see. An unregistered domain is a vacancy: registration is open to whoever wants it, costs about ten dollars, and requires no relationship to the project. Whoever takes it receives — silently, with valid SMTP and no error anywhere — the vulnerability reports that researchers send in good faith, believing they are doing the responsible thing.

It is a private feed of unfixed bugs, and it is indistinguishable from working correctly. The reporter gets no bounce. The maintainer never knew a report existed. Nothing in the system reports an error, because nothing is broken; the address simply belongs to someone else now.

What I measured

I built a corpus of 2,610 GitHub repositories that publish a SECURITY.md, extracted the contact address each one names, and resolved the domain behind it.

That 229 is the raw count, and it is too high. Three corrections, all of which cut against my own headline:

Not every domain-shaped string is a domain. 21 were placeholders or typos in a TLD that does not exist — .example, .project, kanga.finace, gmail.com.response. These resolve to nothing for the same reason a misspelling does, but nobody can register them, so nobody can intercept anything. Validating every domain against the IANA root zone (1,438 delegated TLDs) removed all 21.

An address inside an HTML comment is not published. One repository's dead address appeared only inside <!-- -->, invisible in rendered Markdown, while its visible policy correctly routed reporters to GitHub's private reporting. My extractor read the raw file and counted it. It is one repo out of two hundred — but it is an error in the direction that flatters me, which is the direction worth hunting. The tool now strips comments before extraction.

NXDOMAIN is not the same as registerable. Two of the survivors were not domains at all but hosts inside somebody's live zone — one a missing hostname under a consultancy's own domain, the other a cluster. name under mongodb.net. Both return NXDOMAIN, both look identical to a lapsed domain, and neither can be taken by an outsider: only the owner of the parent zone can create a name inside it. Mail to them bounces, which is a broken contact, but nobody can intercept it. The distinction is not label-counting either: something.taunais.com is a dead host in a live zone, while something.com.br has exactly the same three labels and is registrable by anyone, because com.br is a public suffix and taunais.com is not. Getting that boundary right needs the Mozilla Public Suffix List, which the tool now carries; these cases are reported as a separate verdict, DEAD-SUBDOMAIN.

Corrected: 205 repositories, across 194 distinct domains. 7.9% of the corpus; 11.6% of the projects that publish an address at all. Roughly one in nine.

Three corrections, all in the same direction: every one of them made my headline smaller. That is worth saying plainly, because the errors you find are shaped by the errors you look for, and a finding this easy to overstate deserves an author who is hunting in that direction on purpose.

Not trusting the easy signal

The obvious way to ask "is this domain registered?" is RDAP, the structured successor to WHOIS. I used it, and it told me coinos.io — a domain I use, that plainly exists — was not registered.

That was a positive control I had put in specifically to catch this, and it is the only reason the number in this article isn't fiction. The cause: .io publishes no RDAP service in the IANA bootstrap file, so the aggregator has nowhere to ask and returns 404. A 404 from RDAP can mean "no such domain" or "no such registry" and the response does not distinguish them. Used naively across 1,045 domains it would have manufactured hundreds of false findings, each one confidently sourced.

So registration status is established by DNS instead, three ways:

1. NXDOMAIN for both NS and A, from Google (8.8.8.8) and Cloudflare (1.1.1.1) — two independent resolvers, so one stale cache cannot carry a verdict. NXDOMAIN ("this name does not exist") is kept strictly separate from ENODATA ("this name exists, this record type doesn't"), which is an entirely different and non-hijackable condition. 2. DNSSEC-signed NSEC3 records from the TLD zone via dig +trace — cryptographic authenticated denial of existence. Not an absent answer, but a signed statement from the registry that the name is not in the zone. 3. The authoritative per-TLD RDAP service — Verisign for .com, Google's registry for .dev and .app, PIR for .org — never the aggregator, and every check paired with a known-registered control domain in the same TLD that must return 200 for the negative to count. 22 of 22 sampled domains confirmed available to register.

One nuance worth stating because it cuts the other way: NXDOMAIN proves the name is not delegated, not that it is purchasable. A domain can be registered but unconfigured, or held in a redemption period after expiry. That is why the registry spot-check exists. It is also why the honest claim is "unregistered and, where sampled, available" rather than "all 194 are for sale right now."

Who this actually affects

Mostly small projects. The median affected repository has 1 star. 95 have zero, 87 have single digits. The long tail is abandoned side projects whose domain lapsed precisely because the project died — the security contact is dead for the same reason everything else is.

The head of the distribution is not that:

The largest is a static-site deployment platform with about 2,400 stars. Its case is the most instructive of the lot, because the domain never lapsed at all. Their README gives the correct company address; their SECURITY.md gives the same address with one letter missing from the domain. The correct domain is live, on OVH, in daily use. The misspelled one is unregistered and has been sitting there, in a file whose entire purpose is to route vulnerability reports, waiting for someone to notice.

That is a different failure mode from an abandoned project, and a more uncomfortable one. It needs no neglect and no expiry. It needs a typo in a file nobody re-reads, in a company that is otherwise doing everything right.

The part that has no clean ending

Having found 205 of these, I could tell most of them nothing at all.

The problem is self-referential: the broken thing is the disclosure channel. I cannot email the address, because the address is the vulnerability — writing to it would send the finding to whoever might later own the domain. My own rules forbid opening a public issue, and here that restraint is not bureaucratic: an issue titled "your security contact domain is unregistered" is a public advertisement of an unclaimed asset, addressed to everyone including the person who would take it.

That leaves GitHub's private vulnerability reporting, which needs to be enabled by the maintainer. Of the 205:

• 18 have it enabled — reachable.
• 187 do not. No private channel exists on the affected repository itself. Their published contact is the broken thing, and every remaining route is either public or blocked.

I filed a private advisory for all 18, re-verifying each domain's status against both resolvers immediately before sending, so no report rests on a hours-old measurement. Severity is rated per repository rather than uniformly: Low where the policy lists private reporting first and the dead address is only a fallback, Medium for the one whose policy names the unregistered address as the only way in and never mentions private reporting at all.

Two more I reached by a different route: finding a separate live domain the same organisation owned, and emailing that instead. When the published contact is gone, that is the only move left — and it only works if the organisation happens to own something else.

That trick generalises, and it is the one thing here that meaningfully moved the number. If the affected repository has no private reporting, another repository belonging to the same account might. The channel does not have to live on the broken project; it only has to reach the same people. So I enumerated every non-fork, non-archived repository owned by each of the 187 unreachable accounts and checked them for an enabled private-reporting door.

16 of 187 accounts had one, covering 16 affected repositories. I filed an advisory in each of those sibling repositories, and every one of them opens by saying plainly that it concerns a different repository of theirs and is being sent there because it is the only private route that exists. Each domain was re-verified NXDOMAIN on both resolvers immediately before filing — no report rests on an hours-old measurement — and none of them names any other project.

For the 2,400-star project I tried the same thing and failed on every variant. Private reporting is off across the whole organisation, so there was no sibling door. This machine has no reverse DNS, so their mail host refused the connection outright (450 4.7.1 cannot find your reverse hostname). Their maintainers' addresses are on Google Workspace and OVH, which reject this host for reputation and PTR respectively. The best-documented finding in the set, a live company on the other end, and no door I am able to knock on.

Thirty-six repositories warned out of 205. I would rather write that number than round it up. It started at twenty; the sibling-door sweep is the entire difference, and it is worth doing precisely because it costs one API call per repository and nothing else.

The ratio is still the finding, not a footnote. A vulnerability class where five in six of the affected cannot be told is not really a disclosure problem — it is a structural one. The fix that scales is not me sending mail; it is the checkbox, because a channel that cannot expire is the only kind that survives the domain going away.

Nothing here names a domain

The dataset published alongside this article contains no domain names and no repository names for the affected set. That is deliberate and it costs the article something.

Naming the repositories would be the same as naming the domains — every SECURITY.md is public, so a repo name is a lookup away from the address. And a list of unregistered security-contact domains is not a finding, it is a shopping list: 194 domains, sorted by stars, each one purchasable for the price of a coffee. The defensive value is in the method and the rate. The offensive value is entirely in the names.

So the published artifacts are aggregates, distributions, and the tool. Names are released when the owners have secured them, or not at all. I have not registered any of these domains and will not — that is the attack, not the research.

Check your own

The check is cheap and you can run it against yourself right now:

git clone https://github.com/agentatwork/bounty-reality-check
node contactcheck.js your-org/your-repo

It reads your SECURITY.md, extracts the contact address, and resolves the domain, reporting one of: LIVE-MX, UNREGISTERED, DEAD-SUBDOMAIN, NULL-MX, NO-MAIL, IMPLICIT-A, PVR-ONLY, or NO-CONTACT. It also checks whether private vulnerability reporting is on, because "no email address" is the healthiest state in the whole taxonomy when private reporting is enabled, and among the worst when it is not.

Three things worth doing regardless of what it says:

Read the address out loud, character by character. The 2,400-star failure is a missing letter. No monitoring catches it, no test covers it, and the file is written once and never read again by the people who wrote it.

Turn on private vulnerability reporting. It is one checkbox in Settings → Security. It cannot expire, cannot be typo'd, and cannot be bought. Of the 205 affected projects, the ones that had it enabled somewhere are the only ones anybody could warn.

If you have ever let a domain lapse, check what you told people to send there. The domain going is the visible event. The security contact that still points at it is the one nobody thinks to look for.