CASE · Critical · infra-failure
VerifiedFirsthand recordA cancelled domain stayed wired into a live site, a checkout page and a posting bot
A cancelled domain was still referenced by a live public site's script tag, a payment page, and an automated social posting tool's default config — while the domain itself sat in a state a third party could soon claim.
2 min read
- OBSERVED
- CATEGORY
- infra-failure
- BLAST RADIUS
- reputation, financial, data
- DETECTED BY
- manual-audit
- TAGS
- #domain #dns #supply-chain #automation
CH 1
Cause
Cancelling a domain was treated as a single action, but the domain had been hardcoded as a default value across multiple independent automation pipelines. No single step cleaned up all the places that pointed to it.
CH 2
Consequence
Had the domain been re-registered by someone else before the references were removed, they could have run arbitrary JavaScript on every page of a live site and a payment page, and injected links into an automated posting pipeline.
CH 3
Fix
Before cancelling any domain, grep every project directory for references to it. Never hardcode an external domain as a silent default — if it's unset, fail loudly instead of falling back to something that might not exist anymore.
What happened
A domain used by a since-discontinued referral system was cancelled. Nobody went back to check who was still pointing at it.
The chaos on the ground
WHOIS showed the domain in pendingDelete / redemptionPeriod — meaning it
was about to become available for anyone to register. Meanwhile:
- A live public blog loaded a script tag from that domain on every page
- A payment site loaded the same script and posted sales data plus Basic auth credentials to an API endpoint on that domain
- An already-published social media post still contained a link to it
- An automated posting tool used the domain as a hardcoded default, and one approved-but-unposted draft already contained a link built from it
None of this was exploited. It was caught and closed before anyone could register the domain, but every one of those references was live and waiting.
Root cause
"Cancel the domain" was executed as one action, but the domain had quietly become a hardcoded dependency in several unrelated automation pipelines — a script tag, a webhook target, a default config value. No single cleanup step touched all of them, because no single person or system owned "every place this domain is referenced."
The fix
Before cancelling a domain, search every project for the string first. Don't let an external domain live as a silent default value in code — if it's not explicitly configured, the system should fail with a clear error instead of quietly falling back to something that might now belong to someone else.
Sources
- Firsthand account from the site operator. There is no public write-up to link to.
Pass this record on to your team