Last Wednesday, someone paid us $99 to attack us.
They used a stolen credit card to buy a Pro-tier community on Kazokus. Then they scripted a bot to enroll 4,945 fake "members" through our public invite link. Then they used our Community CRM feature to fire a phishing campaign at every one of them.
It didn't work. Within an hour we had locked the attacker out, deactivated 4,944 fake accounts, downgraded their community back to free tier, and shipped four PRs of defensive infrastructure. Postmark briefly paused our outbound mail, then unpaused it the same day after we walked their abuse team through the diagnosis. No legitimate customer was affected. The stolen credit card will charge back to whoever it actually belongs to.
We are writing this up for three reasons.
1. The bad actor accidentally proved our CRM at scale
The attack hit our CRM email-broadcast feature with a 4,945-recipient blast in a single send. That is the largest single campaign anyone has run on Kazokus. It worked. Every recipient was queued, the templating substituted correctly, the throttling held, the unsubscribe links rendered, the analytics counted. Postmark complained about the content (rightfully so) but not about anything we built.
We had been telling prospective customers our CRM module could handle thousands of recipients per campaign. Now we have proof. We just wish the proof had come from someone with a pulse.
2. If bad actors are looking to exploit you, you have arrived
Sophisticated abuse patterns do not get aimed at platforms nobody has heard of. Stolen-card carding plus scripted account creation plus social-engineering email templates is real engineering effort. Someone went to the trouble of buying a community with a stolen card just to use us as phishing infrastructure. That means we are a credible target.
Six months ago we would not have been worth attacking. As an early stage platform, you take any signals you can get!
3. There is a real lesson here for builders
Three of our defensive layers existed only because a bug enabled them. The most important one, requiring email verification before a public invite link counts a member toward a community's quota, was missing because we wrote a comment in the original code that said:
Set is_verified=True because clicking the invitation email link proves email ownership.
That comment was wrong in a subtle way. The "invitation link" is a public URL. Anyone with the URL can hit the API endpoint directly with whatever email they want. There is no "click." The API does not know whether a human's browser opened the page or a bot scripted a POST.
The bug is the kind of thing you can only see clearly after it has been exploited. We optimized that signup flow for frictionless joining. Enter email, click the button, you are in. That UX intuition was correct, except for the part where it conflated having the URL with controlling the email. Removing friction can be the same shape as opening a door if you are not careful about which assumptions are doing the security work.
We rewrote the entire flow. If you operate a platform that grants any kind of state from a user-supplied email address, ask the same question we should have asked. Is receipt of a URL the same as control of an inbox? It almost never is. Designing as though it were turns a low-friction flow into an open relay.
What changed
Across about twelve hours we shipped multiple fixes to close the loophole and strengthen our overall security posture.
Every layer was tested in production. Each is independently sufficient to break the original attack class. Together they make Kazokus structurally hostile to use as a phishing platform. The attacker would need to control the inboxes of every email they enroll, at which point they do not need us to deliver email anyway.
Your communities are safer today than they were a day ago.
Keep building.
— Mark