Uptimepage

I build an uptime monitor. Part of the job is to attack it before someone else does. Last week I pointed the attack at my own email confirmation flow, and it worked. I could flood any inbox I wanted. If you run anything that sends an email to an address a user typed in, you probably have the same hole.

Here is the mechanism, because it is dumb and that is the point.

Any monitoring tool lets you add an email for alerts. You type an address, it sends a "confirm your email" message, you click the link. Normal. Now read it as an attacker: the tool sends an email to any address I type, and I do not need to own that address. I type the victim's email, hit save, and the confirm mail goes to them.

One email is nothing. But I can make fifty monitors in one account, and there are a hundred tools like mine. A small script signs up, adds the victim to fifty monitors, moves to the next tool. The victim gets a wave of "please confirm" emails from services they have never heard of.

The nasty part: these come from real companies with clean sending reputations. They pass SPF and DKIM, so they land in the main inbox, not spam. A normal spam filter does not save the victim, because on paper none of it is spam. Attackers use the flood as cover, to bury a real bank fraud alert, or to set up a fake "IT help desk" call while the target is panicking.

When I tested mine, the confirm email had no real limit and no clear owner. What actually fixed it, in order:

- Rate limit by the target address, across the whole platform, not per account. Per-account limits do nothing when the attacker opens twenty accounts.

- Say who added the address and to what, right in the email. A stranger should be able to see what is happening at a glance.

- A one-click "this was not me, stop" link that kills the address with no login. RFC 8058 puts that button in the mail app itself.

- Block role addresses like postmaster@ and abuse@, and block your own domains, so a monitor emailing itself cannot start a mail loop.

- Skip the email entirely when the person is logged in with that same address through Google or GitHub. You already know they own it.

None of it is clever. It is boring plumbing. But boring plumbing keeps your name off the list of services used in someone's email bomb.

Full writeup with the attacker view and the reasoning behind each fix: https://uptimepage.dev/blog/email-bombing-uptime-pages

If you run a SaaS with any email confirmation step, spend an afternoon trying to bomb yourself. Have you tested your own signup flow for this? Curious what others found.