Someone Used My Open Source Project To Phish 14000 People

Someone Used My Open Source Project To Phish 14000 People

Introduction

When you publish an open‑source tool that helps teams manage projects, you expect contributions, feature requests, and maybe a few bug reports. You rarely anticipate that the very platform you built will be weaponized to launch a phishing campaign that reaches thousands of inboxes. Yet that is exactly what happened to the maintainer of Kaneo, a self‑hosted project‑management application.

The incident unfolded on a Thursday morning when an email‑delivery service flagged an exhausted sending quota. The root cause was not a sudden spike in legitimate newsletter traffic, but a botnet that had spawned 942 throwaway accounts on disposable‑email providers such as yomail.info, dropmail.me, and spymail.one. Each account created a workspace in Kaneo, embedding a phishing payload directly into the workspace name, and then used the platform’s email‑sending capabilities to broadcast deceptive messages to approximately 14,000 recipients.

For homelab enthusiasts, DevOps engineers, and anyone operating a self‑hosted stack, this episode serves as a stark reminder that infrastructure is only as secure as its weakest configuration. It highlights the importance of:

• Isolation – ensuring that user‑generated content cannot inadvertently expose sensitive services.
• Rate limiting and quota management – preventing a single tenant from exhausting shared resources.
• Secure defaults – avoiding open‑relay or open‑API behaviours that can be abused.

In this guide we will dissect the technical aftermath of the breach, walk through the prerequisites, installation, configuration, and operational hardening of a typical Kaneo‑style stack, and provide concrete, actionable steps to mitigate similar threats in your own environment. By the end, you will have a clear roadmap for:

1. Understanding the architecture of modern open‑source project‑management tools.
2. Deploying them safely on a homelab or cloud host.
3. Hardening the deployment against abuse for phishing or spam.
4. Monitoring, logging, and responding to suspicious activity.

Whether you are running a single‑node Docker Compose stack on a Raspberry Pi or orchestrating a multi‑node Kubernetes cluster, the principles outlined here apply universally. Let’s dive into the details and turn this cautionary tale into a learning opportunity for the entire DevOps community.

---

Understanding the Topic

What is Kaneo?

Kaneo is an open‑source project‑management platform designed to replace spreadsheet‑based workflows with a more collaborative, web‑based interface. It typically ships with the following components:

• A web application written in a server‑side language (e.g., Node.js, Python, or Go).
• A PostgreSQL database for persisting tasks, user data, and configuration.
• An email‑notification service that can send alerts, reminders, and custom messages.
• A workspace model where each project or team occupies its own logical namespace.

The project is intentionally lightweight, making it attractive for self‑hosted deployments in homelabs, small‑business environments, or even larger enterprises that prefer full control over their data.

Historical Context

The concept of self‑hosted project‑management tools dates back to early web‑based solutions like Bugzilla and Trac. Over the past decade, the rise of containerization (Docker) and orchestration (Kubernetes) has democratized the deployment of such tools, enabling anyone with a modest VM to run a fully functional instance. Kaneo emerged as part of this wave, offering a modern UI, API‑first design, and optional cloud‑hosted demo instances.

Key Features

Feature	Description	Typical Use Case
Workspace‑centric architecture	Each project lives in an isolated namespace	Teams managing multiple independent initiatives
Built‑in email notifications	Sends alerts via SMTP or transactional email APIs	Reminders for upcoming deadlines
RESTful API	Enables programmatic access to tasks and users	Integration with CI/CD pipelines
Docker‑first deployment	Official Docker images and Compose files	Rapid homelab setup
Role‑based permissions	Fine‑grained access control	Multi‑tenant environments

Pros and Cons Pros

• Open‑source transparency – code can be audited for security issues.
• Low resource footprint – suitable for low‑end hardware.
• Extensible API – easy to embed into custom workflows.

Cons

• Email‑sending capability can be abused if not properly restricted.
• Default configurations often expose all users to the same SMTP credentials.
• Limited built‑in rate limiting – requires external middleware for high‑volume scenarios.

Real‑World Applications

Self‑hosted project‑management platforms are commonly used for:

• Software development sprints – tracking user stories and bugs.
• Research project collaboration – sharing data and results.
• Event planning – coordinating volunteers and resources.

In each scenario, the ability to send email notifications is a valuable feature, but it also introduces a potential attack surface if not hardened.

---

Prerequisites

Before you begin the installation, verify that your environment meets the following criteria.

System Requirements

Component	Minimum Specification	Recommended
CPU	2 vCPU	4 vCPU
RAM	2 GB	4 GB
Storage	10 GB SSD	20 GB SSD
OS	Ubuntu 22.04 LTS, Debian 12, or CentOS 9	Same, with latest patches
Network	Outbound HTTPS (port 443)	Open inbound only for required services

Software Dependencies

Dependency	Version	Notes
Docker Engine	24.0+	Required for container runtime
Docker Compose	2.20+	For multi‑service orchestration
PostgreSQL	15.x	Used as the primary database
Node.js (if applicable)	20.x	For building front‑end assets
Git	2.40+	To clone the repository

Network and Security Considerations * Firewall – Only expose ports 80 and 443 (HTTP/HTTPS) to the internet; keep the PostgreSQL port (5432) internal.

• TLS termination – Prefer terminating TLS at a reverse proxy (e.g., Caddy, Nginx) before traffic reaches the container.
• User permissions – Run containers under a non‑root user; configure Docker to use a dedicated group for container execution.

Pre‑Installation Checklist

1. Create a dedicated system user (e.g., kaneo) and switch to it.
2. Pull the latest release from the official GitHub repository.
3. Generate a strong secret key for the application (e.g., using openssl rand -hex 32).
4. Configure a local PostgreSQL instance or plan for a managed service.
5. Set up an SMTP relay that enforces rate limits (e.g., SendGrid, Mailgun, or a self‑hosted Postfix).

— ## Installation & Setup

Below is a step‑by‑step guide to deploy Kaneo using Docker Compose. All commands assume you are operating as the kaneo user. ### 1. Clone the Repository

git clone https://github.com/usekaneo/kaneo.git
cd kaneo```  

### 2. Create a `.env` File  

```bash
cat > .env <<EOF
# Application secrets
APP_SECRET=$(openssl rand -hex 32)

# Database connection
DB_HOST=postgres
DB_PORT=5432
DB_USER=kaneo
DB_PASSWORD=SuperSecretPassword
DB_NAME=kaneo_prod

# SMTP configuration (replace with your own provider)
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USER=notification@example.com
SMTP_PASSWORD=SMTP_PASSWORDSMTP_FROM=no-reply@example.com

# Rate‑limit settings (example)
EMAIL_RATE_LIMIT=1000/hour
EOF

3. Build and Start Containers

docker compose pull
docker compose up -d

The compose file defines the following services:

Service	Purpose	Key Environment Variables
web	The main web application	APP_SECRET, DB_HOST, DB_USER, DB_PASSWORD, SMTP_HOST, SMTP_PORT
db	PostgreSQL database	POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB
mailer	Optional transactional‑email sidecar	SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD

4. Verify Container Health

docker ps --filter "name=kaneo" --format "table {{.ID}}\t{{.Names}}\t{{.Status}}" 

You should see all containers in the Up state.

5. Run Database Migrations

docker compose exec web npx prisma migrate deploy

6. Create an Admin User

docker compose exec web npm run create-admin -- --email admin@example.com --password StrongPassword123!

7. Test Email Sending (Optional)

docker compose exec web curl -X POST https://api.resend.com/v1/emails \
  -H "Authorization: Bearer $RESEND_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"from":"no-reply@example.com","to":"test@example.com","subject":"Test","text":"Hello from Kaneo"}'

Note: Replace $RESEND_API_KEY with a valid key from the Resend service.

Common Installation Pitfalls | Symptom | Likely Cause | Remedy |

|———|————–|——–| | Containers repeatedly restart | Insufficient memory or mis‑configured DB_PASSWORD | Increase host RAM or verify .env values | | Connection refused to PostgreSQL | DB_HOST mismatch or network isolation | Ensure postgres service name matches in compose | | Email quota exhausted instantly | No rate limiting on SMTP relay | Configure EMAIL_RATE_LIMIT or use a provider that enforces per‑user limits |

---

Configuration & Optimization ### 1. Secure the Email‑Sending Endpoint

The phishing incident stemmed from an open‑relay‑style configuration where any authenticated workspace could trigger outbound emails. To mitigate this:

• Enable per‑workspace rate limits – enforce a maximum number of messages per hour per user. * Require explicit opt‑in – users must confirm they want to receive email notifications.
• Whitelist allowed sender domains – reject emails that claim to originate from external domains.

Example: Adding Rate Limiting with express-rate-limit (Node.js)

const rateLimit = require('express-rate-limit');

const emailLimiter = rateLimit({
  windowMs: 60 * 60 * 1000, // 1 hour
  max: parseInt(process.env.EMAIL_RATE_LIMIT) || 100,
  message: 'Too many emails sent – please try again later.'
});

app.use('/api/emails', emailLimiter);

2. Harden PostgreSQL Access

• Network isolation – place the database in a separate Docker network that the web container can reach but external hosts cannot.
• Role‑based permissions – create a dedicated DB user for the application with only the required privileges (SELECT, INSERT, UPDATE, DELETE).

Docker Network Configuration

networks:
  kaneo_net:
    driver: bridgeservices:
  db:
    image: postgres:15-alpine
    networks: