A single malicious API call to your email server can sit dormant for hours — then silently hand an attacker complete control of your organization's communications, data, and infrastructure.
Who's at Risk — and How Bad Is It?
Mailcow: dockerized is one of the most widely adopted self-hosted email platforms in the world, used by thousands of businesses, nonprofits, universities, and privacy-conscious individuals who want to run their own email rather than hand it to Google or Microsoft. It handles everything: inboxes, spam filtering, calendars, contacts — the full stack. If your organization runs Mailcow and hasn't updated in the last few weeks, you are currently exposed.
The vulnerability, tracked as CVE-2026-40871, carries a CVSS severity score of 7.2 (HIGH) and enables full remote code execution on the host server. That means an attacker doesn't just read your emails — they can potentially pivot through your entire network, exfiltrate credentials, plant ransomware, or silently monitor communications for months. Any version of Mailcow prior to 2026-03b is affected. Given that Mailcow is almost always deployed in cloud or hybrid environments, the blast radius extends well beyond a single machine.
The "Time Bomb" Attack: How It Actually Works
Here's what makes this flaw genuinely unsettling — it doesn't blow up immediately. Most cyberattacks are loud and fast: someone tries a door, it either opens or it doesn't. This one is different. An attacker sends what looks like a perfectly normal request to your mail server's management interface, creating a new mailbox. Buried inside that request is a tiny piece of poisoned data — something slipped into a field called the "quarantine category," which normally just tells the server how to handle suspicious emails. The server accepts it without question, writes it to the database, and everyone goes home for the day.
Then, hours later — or the next morning, or whenever the server runs its routine quarantine notification job — the trap springs. The server wakes up, fetches that stored data, and tries to use it in an internal database operation. But the data was never just a label. It was a carefully crafted instruction, and the server executes it with full privileges. Attackers call this a second-order injection: the malicious payload is introduced at one point in time and detonates at another, making it dramatically harder to detect in real-time security monitoring. By the time anything looks wrong, the attacker may already have a foothold.
What can they do with that foothold? In the worst case, everything. Email servers are crown jewels — they contain password reset links, financial records, personnel files, customer communications, and authentication tokens. A fully compromised mail server is often the skeleton key to the rest of an organization's digital life. The attacker can create hidden admin accounts, siphon data quietly, or escalate privileges to reach other systems on the same network.
The Technical Detail Security Teams Need to Know
The root cause is a classic but critical implementation failure: the quarantine_notify.py script constructs database queries using unsafe Python % string formatting rather than parameterized queries (also known as prepared statements). The vulnerable value, quarantine_category, is accepted via the /api/v1/add/mailbox endpoint and written to the database with zero sanitization or validation. When the notification job later retrieves and interpolates this value directly into a raw SQL string, any embedded SQL syntax is interpreted and executed by the database engine. This is a textbook second-order (stored) SQL injection — vulnerability class CWE-89 — elevated to remote code execution through the database user's permission level on the host system.
Has Anyone Been Attacked Yet?
As of publication, there are no confirmed reports of active exploitation in the wild. However, security researchers are sounding the alarm urgently — and for good reason. Once a CVE like this is public, the clock starts ticking. Automated scanning tools and opportunistic threat actors typically begin probing for vulnerable instances within days of disclosure, sometimes hours. The deferred nature of the attack also means that exploitation could already be underway at some organizations without any visible indicators yet. The Mailcow development team has patched the vulnerability in version 2026-03b, released in response to responsible disclosure. No specific threat group or campaign has been attributed at this time.
What You Need to Do Right Now
If you or your organization runs a Mailcow instance, take these three steps immediately:
-
Update to Mailcow 2026-03b or later — today, not this week.
Run./update.shfrom your Mailcow directory. This is the only complete fix. Don't wait for a maintenance window on this one — the risk of delay outweighs the inconvenience of a brief service restart. -
Audit your API access logs for suspicious mailbox creation requests.
Look for any calls to/api/v1/add/mailboxfrom unexpected IP addresses or at unusual times, particularly in the days or weeks before you patch. If you find anomalies, treat the server as potentially compromised and escalate to a full incident response process — don't just patch and move on. -
Restrict API access to trusted IP ranges immediately as a stopgap.
If you cannot patch right now, use your firewall or Docker network rules to limit who can reach the Mailcow API endpoint. This won't fix the underlying flaw, but it dramatically narrows the attack surface while you prepare the update. Remove any publicly exposed API keys that aren't strictly necessary and rotate the ones that are.
CVE: CVE-2026-40871 | CVSS: 7.2 (HIGH) | Fixed in: Mailcow 2026-03b | Category: Second-Order SQL Injection / Remote Code Execution