When an Open‑Source SaaS Tool Becomes a Phishing Platform

Andrej Acevski – May 2026

---

What happened

The maintainer of Kaneo, an open‑source project‑management system, runs a hosted version at cloud.kaneo.app so that prospective users can try the product without provisioning their own PostgreSQL instance. On the morning of May 28, 2026 the author received a Resend quota‑exhausted alert. A quick look at the database revealed 942 newly created workspaces, each with a name that looked like a phishing email subject line (e.g., “[BANKING OPERATION] 3.4090 BTC receipt”).

Each workspace had sent roughly a hundred invitation emails, for a total of 14,520 invitations. The emails were sent from the author’s verified Resend domain, carried the workspace name as the subject, and included a link to the legitimate Kaneo site that redirected to a malicious landing page (craftum.io). All invitations were dispatched between 04:00 UTC and 05:30 UTC on the same day, after which Resend’s rate‑limit detection stopped the flow.

No code execution, no broken authentication, and no disclosed vulnerability were involved. The attacker simply signed up for the service, created workspaces, and abused the built‑in invitation feature.

---

Why it matters

Open‑source SaaS vs. self‑hosted expectations

• Self‑hosted: The operator and the users are typically the same entity or a known team. Abuse vectors such as mass‑mailing from a workspace are low‑risk because the operator controls the email reputation and can monitor activity directly.
• Hosted multi‑tenant SaaS: The operator (the project maintainer) vouches for every outgoing message. The provider’s domain reputation, DKIM signatures, and IP reputation are shared across all tenants. When a malicious tenant abuses the service, the provider’s reputation suffers, and third‑party mail providers may flag the domain, affecting legitimate users.

In this case, the attacker leveraged the verified Resend sending domain attached to the SaaS tier. Because the domain was trusted, spam filters treated the invitations as legitimate, dramatically increasing delivery rates.

Design choices that enabled abuse

Feature	Intended purpose	Abuse potential
Open signup (no captcha)	Lower friction for developers to try the product	Automated account creation at scale
Unlimited workspace creation	Flexibility for teams	Attackers can generate thousands of unique sender identities
Invitation endpoint without rate limiting	Easy collaboration	Bulk spam possible
Workspace name used as email subject	Simple UI	Allows attackers to embed phishing subject lines
Guest accounts allowed to send invites	Quick onboarding for external collaborators	Enables unauthenticated spam

The combination of these defaults created a low‑effort path for a phishing campaign.

---

The response

1. Immediate containment – The author revoked the Resend API keys, exported all bot accounts, workspaces, and invitation records to CSV for evidence, and performed a single PostgreSQL transaction to delete the malicious data (DELETE FROM users WHERE id IN (…)).
2. Hardening measures (implemented within a day)
   • Added captcha to the signup flow.
   • Blocked known disposable email domains (e.g., yomail.info, dropmail.me).
   • Introduced rate limits on the /invite endpoint (e.g., 10 invites per minute per user).
   • Implemented a workspace‑name filter that rejects strings matching common phishing patterns (bank names, crypto amounts, excessive numeric tokens).
   • Disabled invitation sending for guest accounts.
3. Policy shift – The maintainer now treats the cloud tier as a distinct product with its own threat model, separate from the self‑hosted version. Future feature releases for the SaaS tier will include abuse‑prevention defaults, while the self‑hosted code path remains unchanged to avoid penalising legitimate users.

---

Lessons for other open‑source SaaS projects

Lesson	Practical tip
Separate threat models	Document separate security assumptions for self‑hosted and hosted deployments. Treat the hosted tier as a public SaaS offering, not just a convenience layer.
Validate identity early	Require captcha or email verification (with a delay for disposable domains) before allowing any privileged actions such as bulk email.
Rate limit privileged APIs	Apply per‑user and per‑IP throttling on endpoints that can trigger external communication (e.g., invites, webhook registrations).
Sanitize user‑generated content used in email headers	Strip or reject workspace names that contain high‑entropy tokens, bank names, or cryptocurrency amounts.
Monitor outbound email reputation	Use a service that flags unusual sending patterns (spike in volume, new sender domains) and automatically suspends the offending account.
Provide abuse‑reporting hooks	Offer a simple way for recipients to report phishing attempts, and automate the revocation of offending accounts.

---

Where to find the project and the incident details

• Kaneo source code – https://github.com/kaneo/kaneo (MIT license)
• Resend email service – https://resend.com (used for transactional mail)
• Post‑incident write‑up – the author’s blog post (original text) provides a step‑by‑step reconstruction of the attack and the remediation process.

---

Closing thoughts

The incident is a reminder that the convenience of a hosted, open‑source SaaS layer comes with responsibilities that differ from those of a self‑hosted tool. Even when the underlying software has no exploitable bugs, the operational design can become a vector for abuse. By treating the cloud tier as a separate product, applying early verification, and enforcing rate limits, maintainers can protect both their own reputation and the users who rely on the service.