One phishing page took down every site we hosted

Post-mortem

One phishing page took down every site we hosted

A single user published a fake login page. Within hours, Google flagged our entire domain and the registry pulled it out of DNS, knocking hundreds of unrelated sites offline at once. Then we discovered we'd boxed ourselves into a catch-22 that kept us from fixing it. Here's what broke, the trap we walked into, and what we changed so neither can happen again.

boomurl engineering · 2026

boomurl is about the smallest useful thing a web host can be. You drag a file (an HTML page, a Markdown doc, a PDF, or a whole folder) onto the page, pick a name, confirm a code, and roughly 20 seconds later you have a real HTTPS URL. No account, no build step, no dashboard. It's the "just put this on the internet" button.

That simplicity is the point. It also turns out to be an open invitation to the internet's least pleasant people.

What happened

For most of boomurl's life, every published site lived on one domain, path-based: boomurl.site/alice, boomurl.site/bob, and so on. One afternoon someone used that 20-second flow to publish a convincing bank-login phishing page on it.

Google Safe Browsing noticed, as it should. But Safe Browsing, and the registry that acted on it, don't reason about /alice vs /bob. They work at the level of the registrable domain . So the flag didn't land on one path. It landed on the whole host:

Blast radius of one pagethe entire platform

Google Safe Browsingdomain-level "dangerous" interstitial

Registry actionserverHold, pulled from DNS

Reaching the registrydays of silence

Our Search Console standingnone, never registered

Sites affectedevery single one

Every user who had ever published (people with resumes, demos, wedding pages, side projects) suddenly got a full-screen red warning, then nothing at all once the domain stopped resolving. None of them had done anything wrong. The shared origin was the vulnerability.

If you host user content on one domain, you are always one bad page away from a platform-wide reputation event. We learned that the expensive way.

The part that actually hurt: a catch-22

The phishing page was bad. What made it a week-long problem instead of an hour-long one was the corner we'd painted ourselves into.

.site is run by a registry (Radix), and once Safe Browsing flagged us, that registry put boomurl.site on serverHold. That status yanks the domain out of DNS completely, so it stops resolving for anyone. Not a warning page. Gone. Our sites, our API, everything on that domain.

To get a Safe Browsing flag reviewed, you ask Google to re-check the site, and you do that through Google Search Console. To do anything in Search Console, you first have to prove you own the domain, normally by publishing a DNS record on it or serving a file from it. But the domain was on hold and out of DNS, so we couldn't publish a record or serve a file from it. And we had never verified boomurl.site in Search Console back when it was healthy, so we had no standing there at all.

Every door was locked at the same time:

We couldn't clear the flag without Search Console.

We couldn't get into Search Console without a domain that resolved.

We couldn't get the domain resolving again without the registry lifting the hold.

And the registry, reachable only through our registrar, went quiet. Days passed with no human on the other end.

That loop is the single most important thing to avoid, and it's the reason this article exists. The phishing page wasn't the real failure. Phishing is just a fact of life once you let strangers publish. The real failure was that the only way back online ran entirely through a support queue we didn't control, and we'd set up no fallback of our own ahead of time.

There was one free step that would have broken the whole loop, and we'd skipped it.

Verify every domain in Google Search Console the day you buy it, while it still resolves. It's free, it takes two minutes, and it's the one foothold that survives your domain going dark.

We did exactly that for the new domain before moving a single site onto it. If we're ever flagged again, the appeal channel already exists, verified and waiting, no matter what any registry decides to do. Boomurl.site, for the record, never came back. We stopped waiting on the registry and moved on.

The core mistake: shared blast radius

The diagram below sums it up. On the left is what we had: one origin, everyone's content mixed together, so a single flagged page reddens the entire surface. On the right is what a host that survives this looks like. Every site sits on its own origin, so a flag is contained to exactly one.

BEFORE: shared domain<br>host.tld/

one page flagged →<br>the whole domain goes dark<br>+ registry serverHold = NXDOMAIN

NOW: per-site origins<br>.host.tld

one page flagged →<br>only that one subdomain is affected<br>everyone else stays green & online

Same phishing page. On a shared origin it's total loss. On...