- An open source phishing attack sent 14,520 scam emails using a developer’s verified domain without breaking a single line of code.
- The open source phishing campaign exploited Kaneo’s cloud signup form, creating 949 fake workspaces in a three-hour window overnight.
- No CVE was filed — the attacker simply used the product as designed, exposing a blind spot in how open source cloud tiers are secured.
- The incident reveals a broader truth: hosting a free cloud tier means vouching for everything strangers do through your infrastructure.
Open Source Phishing Without a Single Exploit
Open source phishing doesn’t usually make headlines the way a zero-day does. There’s no dramatic breach, no stolen database, no CVE number to tweet about. Sometimes the attack is just a signup form, a verified email domain, and a threat actor who did their homework. That’s exactly what hit Andrej, the developer behind Kaneo, a lightweight open source project management tool, last Thursday morning — and the story is worth understanding in full.
The alert came from Resend, a developer-focused email API service. His sending quota for cloud.kaneo.app was gone. He hadn’t sent anything in days. A quick SSH session and one database query later, the picture was clear: 949 new workspaces had appeared in a three-hour window overnight on May 28th, each created by a throwaway account from domains like yomail.info, dropmail.me, and spymail.one. Every workspace had the same basic structure — a name that read like a phishing email subject line, complete with crypto amounts, bank names, and invented presenter names. Something like: 🔒Paul Brown from BANKING OPERATION invited you to join 3.4090_BTC receipt.
Each of those 949 accounts had sent roughly a hundred invitation emails. That’s 14,520 outbound messages, all signed with Andrej’s DKIM credentials, all carrying his domain’s sender reputation, all pointing recipients to a link on craftum.io with a tracking suffix. By the time he woke up, the campaign was already over. Resend’s rate detection had caught it after about ninety minutes of clean sends. The attacker had timed the operation for 4am UTC on a Thursday — a calculated choice that bought them maximum sending time during low-traffic hours.
Why the Attack Worked So Cleanly
This is where the story gets genuinely uncomfortable. There was no vulnerability here in any traditional sense. The attacker didn’t reverse-engineer an API, didn’t find an authentication bypass, didn’t chain together some elaborate privilege escalation. They filled out a signup form. Nine hundred and forty-two times. They created workspaces. They sent invitations. They used the product exactly as it was designed to be used.
What made that useful for open source phishing was a specific combination of features that individually seem harmless: open, unverified signup; no CAPTCHA; no rate limits on invitation sending; no filter on workspace names; and — critically — a verified sending domain attached to all of it. Andrej put it plainly: “I had a verified email-sending domain attached to open, unverified signup, and that’s a useful primitive if you don’t care what you send.”
The attacker clearly understood this. The workspace name template wasn’t random — it rotated through variations on bank names, crypto amounts, and fake presenter names in a way that suggests prior testing and iteration. The recipient list was almost certainly purchased. This wasn’t opportunistic. Someone had evaluated Kaneo’s cloud tier as a delivery mechanism and decided it met their requirements for an open source phishing operation.
The invitation email body itself was innocuous: a polite note saying someone had invited you to join a workspace on Kaneo, with a “click here to accept” button pointing at the actual Kaneo site. The scam payload lived entirely in the workspace name — the email subject line — and the craftum.io link embedded there. It was just convincing enough to fool people who weren’t paying close attention, and that’s all a phishing campaign needs.
The Real Cost: Domain Reputation and 14,000 Strangers
Fourteen thousand people received a phishing email from a domain they had no reason to distrust. That’s the number that matters most here, and it’s not an abstract risk — it’s concrete harm to real inboxes. Andrej was direct about the responsibility: “The 14,000 phishing recipients are not my users, but my domain landed in their inboxes, and that’s on me.”
Beyond the human impact, there’s the infrastructure cost. Email sender reputation is painstakingly slow to build and can be devastated quickly. Resend’s own deliverability depends partly on the aggregate behavior of its customers — which is why the platform has rate detection in the first place. A wave of 14,000 phishing emails carrying DKIM signatures from a legitimate domain poisons relationships with mail providers that can take months to repair. Google, Microsoft, and other major inbox providers track sending patterns at the domain level. Even after cleanup, Andrej’s domain carries the statistical fingerprint of this open source phishing incident.
The cleanup itself was relatively fast — about an hour of database work. He revoked the Resend keys immediately, then ran a single Postgres transaction that banned 942 users, deleted 947 workspaces, and cascaded out all 14,533 invitations via foreign keys. He ran it with ROLLBACK first to verify the counts, then committed. The hardening that followed — CAPTCHA on signup, disposable-email blocking, rate limits on the invite endpoint, a workspace-name filter, and a rule preventing guest accounts from sending invitations — took about a day.
Open Source Phishing Exposes a Cloud Tier Blind Spot
What’s most instructive about this incident isn’t the attack itself — it’s the mental model failure that made it possible. Andrej had been thinking of cloud.kaneo.app as “the same software, hosted for you.” That framing is common across the open source space. Dozens of projects — from database tools to CMS platforms to dev utilities — offer a hosted cloud version as a convenience layer on top of a self-hosted core. The pitch is usually something like: try it here, then run it yourself when you’re ready.
The problem is that the threat model for a self-hosted deployment and the threat model for a multi-tenant SaaS are completely different animals. In a self-hosted setup, the person running the software and the person using it are either the same individual or people who already know each other. Adversarial behavior toward external systems simply doesn’t arise — there’s no incentive to spam yourself. Rate limits and signup friction aren’t necessary because the attacker surface doesn’t exist.
Multi-tenant cloud changes everything. The operator — in this case, Andrej — vouches for every action every user takes against every external system the platform touches. Resend doesn’t distinguish between an invitation Andrej sent and one a throwaway account sent through his deployment. His DKIM signature is on both. His IP reputation is on the line for both. Open source phishing through a hosted cloud tier is particularly effective precisely because the operator’s verified credentials lend legitimacy to every message the platform sends. “For 14 months no one cared, and then someone did” — and that someone used the product’s own trusted infrastructure against thousands of strangers. This is the blind spot that open source phishing exposes most clearly: the moment you attach a verified sending domain to an unauthenticated public signup flow, you have handed attackers a delivery mechanism that looks, to every spam filter in the world, exactly like you.
Source: https://andrej.sh/posts/phishing-through-my-open-source-project
