CVE-2024-24760: Mailcow Dockerized Email SSRF Vulnerability

CVE-2024-24760 Overview

CVE-2024-24760 affects mailcow, a dockerized email package that links multiple containers within a bridged Docker network. Versions prior to 2024-01c expose internal container ports to attackers on the same subnet, even when those ports are bound to 127.0.0.1 on the host. The flaw stems from Docker's default networking behavior, which bypasses host-based loopback restrictions when packets arrive through the bridge interface. Affected services include MariaDB (3306), Redis (6379), Apache Solr (8983), and an internal service on port 12345. This vulnerability is classified under CWE-610 (Externally Controlled Reference to a Resource in Another Sphere).

Critical Impact
Adjacent-network attackers can reach mailcow database and cache services intended to be loopback-only, exposing email data and enabling credential theft.

Affected Products

mailcow: dockerized versions prior to 2024-01c
Deployments exposing containers on shared subnets or virtualized bridge networks
Installations relying on 127.0.0.1 host port bindings for isolation

Discovery Timeline

2024-02-02 - CVE-2024-24760 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-24760

Vulnerability Analysis

The vulnerability arises from how Docker handles port publishing on bridged networks. When mailcow binds a container port to 127.0.0.1:<port>, administrators expect the service to be reachable only from the host loopback. Docker's default FORWARD chain in iptables, however, permits traffic from external interfaces to reach the container's internal IP directly through the bridge, bypassing the loopback binding.

Attackers on the same Layer 2 broadcast domain, such as a shared LAN, VLAN, or virtualization host, can craft packets targeting the container's private IP address on ports 3306, 6379, 8983, or 12345. This grants direct access to MariaDB, Redis, Solr, and the mailcow API service without traversing the intended authentication layers.

Root Cause

The root cause is missing egress filtering on the br-mailcow bridge interface. mailcow relied on Docker's host-port binding for network isolation without applying additional netfilter rules. Any packet routed to a Docker-published container was accepted regardless of ingress interface, permitting adjacent hosts to bypass the intended loopback restriction.

Attack Vector

Exploitation requires network adjacency and low privileges. An attacker on the same subnet enumerates the mailcow host, identifies the Docker bridge subnet, and connects directly to container IPs on the vulnerable ports. Successful connections yield database queries, cache manipulation, or search-index access, depending on the targeted service.

bash

# Patch fragment: additional Dovecot replica configuration introduced
# alongside the netfilter fixes in the mailcow patch branch
if [[ -n ${MAILCOW_REPLICA_IP} && -n ${DOVEADM_REPLICA_PORT} ]]; then
  cat <<EOF > /etc/dovecot/mail_replica.conf
# Autogenerated by mailcow
mail_replica = tcp:${MAILCOW_REPLICA_IP}:${DOVEADM_REPLICA_PORT}
EOF
fi

Source: mailcow-dockerized commit 087481a

Detection Methods for CVE-2024-24760

Indicators of Compromise

Unexpected TCP connections to Docker bridge IPs on ports 3306, 6379, 8983, or 12345 originating outside the br-mailcow interface
MariaDB authentication failures or successful logins from non-loopback source addresses in mailcow container logs
Redis MONITOR, KEYS *, or CONFIG GET commands issued from unfamiliar client IPs
Solr query traffic on 8983 from hosts other than the mailcow application container

Detection Strategies

Audit host iptables and nftables rulesets for a DROP rule enforcing ! -i br-mailcow -o br-mailcow on the vulnerable ports
Compare running mailcow release tags against 2024-01c or later using git describe in the deployment directory
Capture bridge-interface traffic with tcpdump -i br-mailcow to identify unauthorized source addresses

Monitoring Recommendations

Forward Docker daemon logs and container access logs to a centralized SIEM for correlation
Alert on new TCP sessions to internal container subnets from non-container source IPs
Baseline expected inter-container communication and flag deviations, particularly to MariaDB and Redis

How to Mitigate CVE-2024-24760

Immediate Actions Required

Upgrade mailcow to release 2024-01c or later, which introduces the netfilter rules that block adjacent-network access
Restart the Docker daemon after upgrade to ensure the new iptables and nftables chains are installed
Restrict physical and logical network access to the mailcow host, placing it on a dedicated management VLAN where feasible

Patch Information

The upstream fix is applied in mailcow commit 087481ac12bfa5dd715f3630f0b1697be94f7e88, referenced in the GitHub Security Advisory GHSA-gmpj-5xcm-xxx6. The patch adds iptables and nftables rules that drop packets destined for ports 3306, 6379, 8983, and 12345 when the input interface is not br-mailcow and the output interface is br-mailcow.

Workarounds

Manually insert equivalent iptables rules on the DOCKER-USER chain to block adjacent-network traffic to the affected ports until the upgrade is applied
Bind mailcow to a dedicated network interface accessible only to trusted management hosts
Deploy an upstream firewall or security group that filters traffic to the host on ports 3306, 6379, 8983, and 12345