Mailcow

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 6 Last 12 months 22 Lifetime Stored XSS 50 % SQL injection 20 % Missing authorization 20 % Input validation 10 % Latest advisories Loading the feed Overview Mailcow is the turnkey answer to self-hosting mail: one Docker Compose stack wiring Postfix, Dovecot, rspamd, SOGo and ClamAV together behind a PHP administration panel. Small hosting outfits and managed service providers run it as the mail platform for an entire customer base, so that panel sits on the public internet with every mailbox behind it. CVE-2026-40872 is the reference point, a critical stored scripting flaw where the email field in the autodiscover log fired inside the panel itself. Twenty-two advisories have been published over the project's life and none of them earned anyone money, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy asks for security vulnerabilities by email to the mailcow team and describes a coordinated fix process. It draws no boundary narrower than the stack mailcow ships, so everything mailcow itself writes or wires together is inside it The mailcow UI in full: the administrator panel, the domain-admin panel and the mailbox-user panel, three different privilege levels on the same application The mailcow API, including API-key authentication and every endpoint that creates, modifies or deletes a mail object The quarantine interface, where an administrator reads attacker-supplied subject lines, sender addresses and attachment filenames inside a privileged browser session Autodiscover and autoconfig, the endpoints a mail client hits before it has been configured and which answer without authentication Logging and log display: the login history, the autodiscover log and every other view rendering data a remote party supplied The authorization model across the three panel levels, covering what a domain admin or a mailbox user can reach of another tenant's configuration Aliases, forwarding hosts, relay settings and everything else deciding where mail leaves this server for Two-factor handling, app passwords and the session machinery behind the panels The container orchestration mailcow ships: the compose definitions, the entrypoint scripts, the update mechanism and the secrets passed between containers Out of scope Defects inside the bundled upstreams themselves. Postfix, Dovecot, rspamd, SOGo and ClamAV are separate projects with separate maintainers, and a bug in their code is their report Operator configuration, including a panel exposed without a reverse proxy, weak administrator passwords or a deliberately open relay The Docker daemon, the host operating system and the TLS termination an operator put in front of the stack Outdated deployments. mailcow updates in place and the published advisories all assume a current stack Volumetric denial of service against a mail server that accepts mail from strangers by design Missing security headers and scanner output with no demonstrated impact, which on a panel this size is a very large category Most-valued findings Stored cross-site scripting firing in an administrator's session. It is what this project's record is mostly made of: CVE-2026-40872 was rated critical for the autodiscover log's email field, and CVE-2026-40873 and CVE-2026-40875 did the same through quarantine attachment filenames and a login-history IP field Any path where remote, unauthenticated input reaches a privileged panel view. The three above all worked that way, and the quarantine and log surfaces are full of comparable fields SQL injection through the API, including second-order cases where a payload is stored first and executed later. CVE-2026-40871 sat in the quarantine category parameter Missing or incorrect authorization on API endpoints, the class CVE-2026-40874 landed in, and the one letting a domain admin or mailbox user act outside their tenant Anything crossing the tenant boundary on a shared deployment, since small hosts run one mailcow for many unrelated customers Authentication bypass on the panels or the API, including two-factor handling and app passwords Escape from the integration layer into the containers underneath, where mailcow's own scripts hold the credentials every bundled daemon uses Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report by email to the mailcow team at [email protected] , the address SECURITY.md names, or through GitHub private vulnerability reporting on mailcow/mailcow-dockerized , which is also switched on The project documents a handler assignment and a coordinated fix process, so expect a named person and a tracked issue rather than a black hole Establish which component owns the bug before filing. mailcow bundles Postfix, Dovecot, rspamd, SOGo and ClamAV, and each of those is a separate upstream with its own reporting channel mailcow's own code is the admin UI, the API and the integration glue between containers. That is where the entire published advisory record sits If your finding is inside SOGo, note that its vendor documents no security channel anywhere and its bug tracker requires an account upgrade before you can file at all. Raise it with mailcow and expect the coordination problem to be real There is no payment to negotiate: no bounty, no reward terms and no security.txt on either project domain Disclosure Coordinated by email with the mailcow team, with a documented handler assignment, and published as GitHub Security Advisories alongside a release. The record moves in batches: all six advisories from the past year went out together on 16 April 2026, on top of twenty-two published over the project's life. Plan for an embargo running to the next batch rather than to a fixed day count. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability