mailcow footer template flaw let domain admins run code in shared rspamd container

What happened

A security advisory for mailcow, the self-hosted dockerized mail platform, describes a flaw that allowed a domain administrator to escape their assigned tenant and execute code inside a component shared by every domain on the server. The issue is tracked as CVE-2026-125757 and published as GitHub advisory GHSA-jgr3-fv33-x43c. According to a write-up on dev.to, mailcow: dockerized releases before 2026-11 are affected, and the 2026-11 release carries the fix.

Although the vulnerable feature accepts HTML, this goes beyond cross-site scripting: the advisory classifies it as stored server-side template injection, meaning the payload runs on the server rather than in a victim's browser.

How a footer becomes code execution

The way in is the domain-wide footer. A domain administrator sets it by calling the API endpoint POST /api/v1/edit/domain/footer, and the advisory says the submitted value is kept exactly as provided. When mail goes out, mailcow hands the footer to rspamd's MOO_FOOTER processing, which renders it with the jinja/lupa template engine.

Template syntax in that footer is evaluated rather than treated as inert text. The advisory explains that a carefully built macro can invoke Lua's os.execute, and the resulting code lands inside the rspamd container. Sending a single authenticated outbound message from the domain is enough to trigger the rendering path.

The bar for exploitation is low. The attacker needs a domain administrator account and the ability to send from that domain; the advisory stresses that no global administrator role, no host access and no special network position is required.

Consequences reach every tenant

Because the rspamd container is shared across the deployment, the compromise is not confined to the attacker's own domain. According to the advisory, the executed code can read, alter or inject any tenant's mail while it is in transit, capture credentials carried in those messages, and switch off spam and antivirus filtering for the whole platform. The code can also reach rspamd's Redis connection.

There is a second-stage path as well: after gaining code execution, an attacker can publish a message on MC_CHANNEL that the dockerapi subscriber translates into a container lifecycle operation, opening a route to platform-wide denial of service. The dev.to write-up is careful to note that this is a downstream consequence rather than the entry point, with the footer rendering being the root problem.

Patching and incident response

The remediation is straightforward in outline: upgrade to mailcow: dockerized 2026-11 or later, delete malicious or unnecessary domain-wide footers, rotate API credentials, mail credentials and any secrets reachable from the rspamd container, and review which accounts hold domain administrator roles.

For incident response, operators are advised to comb the rspamd container and deployment logs for odd child processes, surprising outbound network connections and container restarts. Mail that crossed the scanner while a vulnerable version was in place should not be considered trustworthy without additional review. Operators are also warned not to close the investigation after resetting one administrator's password, since every domain whose administrator could have reached the shared scanner needs checking.

Tenants on hosted mailcow deployments are advised to ask their provider whether an affected release was running and whether domain administrator accounts were handed to third parties, and to audit footer history, API tokens and outbound mail logs around the exposure window.

Why it matters

The bug is a textbook case of how multi-tenant self-hosted software fails: a setting scoped to one tenant quietly flows into infrastructure that everyone shares, and a template engine turns a configuration field into arbitrary code execution. The lesson for operators extends past this one patch: audit every tenant-controlled field that reaches a template engine or shell-like interface, log who changed templates and when, and alert on scanner restarts and unexpected child processes. For anyone running mail on shared infrastructure, it is a reminder that a provider's domain administrator role can, in the wrong software, amount to full control of the mail platform.