mailcow Domain Administrators Could Reach a Shared Scanner Through a Footer Template
A domain administrator normally controls domain-specific mail settings. In mailcow, those settings can cross into a service shared by every hosted domain. Security advisory GHSA-jgr3-fv33-x43c describes a stored server-side template injection through a domain-wide footer.
The issue affects mailcow: dockerized versions before 2026-11 and is fixed in 2026-11. It is tracked as CVE-2026-125757.
From footer to scanner
A domain administrator stores HTML in the domain-wide footer through POST /api/v1/edit/domain/footer. The advisory says the value is stored verbatim. mailcow then supplies the footer to rspamd's MOO_FOOTER processing and renders it with the jinja/lupa template engine.
Template syntax in the footer is evaluated. A crafted macro can reach Lua os.execute, and the code runs inside the rspamd container. One authenticated outbound message from the domain triggers the rendering path.
The attacker needs a domain administrator account and the ability to send from that domain. No global administrator role, host access or special network position is required. The impact nevertheless crosses the tenant boundary because the rspamd container is shared by the deployment.
Cross-tenant consequences
The advisory says the attacker can read, modify or inject every tenant's mail in transit, harvest in-transit credentials and disable spam or antivirus filtering for the platform. The code can also reach rspamd's Redis connection.
After code execution, the attacker may publish a message on MC_CHANNEL that the dockerapi subscriber turns into a container lifecycle action. That creates a platform-wide denial-of-service path, but it is not the initial entry point. The footer rendering is the first problem.
What tenants should ask the operator
Hosting customers should ask whether their provider runs an affected mailcow release and whether the domain administrator role was assigned to third parties. Domain administrators should review footer history, API tokens and outbound message logs around the incident window.
Operators should inspect the rspamd container and deployment logs for unexpected process activity, outbound connections and container restarts. Mail that passed through the scanner during the exposure window cannot be assumed trustworthy without additional review.
Remediation
Upgrade to mailcow: dockerized 2026-11 or later. Remove malicious or unnecessary domain-wide footers. Rotate API credentials, mail credentials and secrets available to the rspamd container. Review tenant roles and separate administrative duties where the platform permits it.
Because the issue is tenant-to-platform, an operator should not close the incident after resetting one domain administrator's password. Check every domain whose administrator could leverage the shared scanner.
Control the template boundary
The fix belongs in the code, but the incident review should ask whether other tenant-controlled fields reach template engines or shell-like interfaces. Log the source of template changes and alert on rspamd restarts, unexpected child processes and messages that modify container state.
