← Tools I Use

When your open-source side project becomes phishing infrastructure

2026-06-02 · ~6 min read · Conor Dobbs

A developer named Andrej open-sourced a project management tool called Kaneo. It has a self-hosted version and a hosted cloud version, the normal "use it yourself or let me run it for you" split. Then someone signed up for the cloud version about 942 times, and used it to send 14,520 phishing emails in roughly three hours.

He found out the way most people find out their infrastructure is on fire: an alert. His Resend sending quota was exhausted. By the time he looked, the attacker had created hundreds of accounts with throwaway email addresses, made a workspace inside each one, named each workspace after a phishing subject line, and fired off about a hundred "you've been invited" emails per workspace to a list of strangers. Every one of those emails went out from his verified sending domain.

The line from his write-up that stuck with me: they used the tool exactly as designed. The design was just bad enough that the tool was good for phishing.

Why this is worth your attention even if you'll never run Kaneo

I build hosted tools for a living. A cron monitor, a webhook inspector, a website security scanner, a token-usage tracker. Every one of them is a public endpoint that anyone on the internet can hit without asking me first. So when I read this I did not think "unlucky guy." I thought "that is the exact failure mode I spend the most time on, and the only reason it has not happened to me yet is that I got paranoid early."

Here is the uncomfortable part. None of the things the attacker did were a hack. There was no exploit, no CVE, no leaked credential. The signup form worked. The invite system worked. The email delivery worked. The attacker combined four perfectly reasonable features into a weapon:

Any one of those alone is fine. Most products ship with all four on day one because each one individually makes the product easier to try. Stack them and you have built a free, reputable, deliverable phishing relay and put your own domain's name on it.

The thing self-hosting hides from you

The self-hosted version of Kaneo was never the problem. If you run it yourself, you own the signup page, the sending domain, and the blast radius. You are the only user, or your team is, and abuse is your own problem on your own infrastructure.

The moment you offer a hosted version, the math inverts. Now strangers create accounts. Now your sending domain vouches for their content. Now your reputation, your IP ranges, and your deliverability are the resource being spent. The open-source maintainer mindset is "ship the feature, let people use it." The hosted-service mindset has to be "assume the worst person on the internet will sign up within the hour and ask what they can do with my account."

That shift is not obvious, and nobody warns you about it when you flip on the cloud version. You think you are doing the same thing you were doing before, only now for other people. You are not. You are now an email sender, an identity provider, and an abuse target, on top of being a project maintainer.

What he changed, and what it teaches

His cleanup was clean: he deleted all 942 fraudulent accounts and their data in a single database transaction, inside an hour. Then he hardened the cloud version with the obvious set, CAPTCHA on signup, disposable-email blocking, rate limits on the invite endpoint, a filter on workspace names, and a rule that guest accounts cannot send invitations at all. Crucially, he applied those only to the hosted version. The self-hosted experience stayed friction-free, because self-hosters are not the threat.

That last decision is the mature one. The lazy fix would have been to bolt friction onto everyone. The right fix was to recognize that the hosted deployment has a different threat model than the code, and to defend the deployment specifically.

The order that actually matters

If you are about to put a hosted version of anything in front of the public, the lesson is not "add a CAPTCHA." It is "figure out which of your features become abusable the second a stranger can use them, before you launch, not after the quota alert."

For me the tell is always the same: any unauthenticated endpoint that produces an outbound effect. Sending an email. Making an outbound HTTP request. Writing to shared storage. Costing money per call. When I shipped a free website scanner recently, the first thing I added before anyone could find it was a per-IP rate limit, because the scanner makes outbound requests to whatever URL you hand it. Without a limit, one person on a busy day could point my server at a third party and let my IP take the blame, while burning my request quota. Same shape as Andrej's invite endpoint. The features were the attack surface.

A short checklist I now run before any hosted launch:

You will not catch everything. Andrej clearly did not, and he is a careful engineer. But the goal is not perfection. The goal is to make your tool boring to abuse, so the attacker moves to the next open signup form instead of yours.

The honest summary

Open source is a generosity machine. The instant you also host it, that same machine will be tested by people who read "free, deliverable, reputable" as an invitation. Treat the hosted deployment as a separate product with its own threat model. Verify before you trust your own defaults. The features you are proudest of shipping are the same ones an attacker will reach for first.

Sources