mailcow-dockerized contains a stored cross-site scripting vulnerability in the administrator Queue Manager

CVE-2026-7460 is a stored XSS in mailcow-dockerized's administrator Queue Manager. In affected release 2026-03b, queue metadata returned from /api/v1/get/mailq/all is copied into DataTables rows and some fields are rendered as HTML without output encoding; the Fluid Attacks write-up calls out sender, queue_name, queue_id, and queue_id-derived fragments as sinks. Practically, an attacker who can get a crafted message stuck in the Postfix queue can plant markup in queue metadata and wait for an administrator to browse /admin/queue.

This is not a fire-drill internet RCE, and treating it like one would waste patching capital. The impact is serious if it lands — privileged browser execution in an admin session can mean same-origin actions, config changes, mailbox tampering, or account takeover — but the chain has real friction: one known affected release, queue persistence is required, and an authenticated admin must visit a specific operational page that many teams open only during troubleshooting.

Why this verdict

• Requires a prior queueing condition: the attacker must get a crafted message to persist in Postfix queue metadata long enough to be rendered, which is a real operational hurdle and pushes the score down from what stored XSS looks like on paper
• Requires authenticated admin page view: the exploit does nothing unless an administrator opens /admin/queue; that is a niche troubleshooting workflow, not normal user traffic, so reachable population is materially smaller
• Narrow version scope: the available authoritative write-ups point to a single affected release, 2026-03b, and the vendor's 2026-05 release already shipped the queue-manager HTML escaping fix

Why not higher?

Because this is not a broadly triggerable web bug. It is chained: queue persistence, specific metadata path, authenticated admin context, and a particular page view. Those compounding prerequisites mean the vendor-style technical impact overstates real fleet risk.

Why not lower?

Because if the chain lands, the attacker gets script execution in a privileged admin origin, which is enough for same-origin API abuse and effective control of the mail platform. For organizations where mail admins routinely inspect queues during incidents, the exploitability is low-frequency but not theoretical.

1. Restrict admin UI reachability — Put the mailcow admin UI behind VPN, IP allowlists, or an identity-aware proxy so the admin session is not casually reachable from the open internet. For a MEDIUM verdict there is no mitigation SLA, so fold this into normal hardening while still targeting the actual patch within the 365-day remediation window.
2. Monitor and age out suspicious queue entries — Alert on queued messages with malformed or HTML-like envelope sender values and reduce queue dwell time where operationally safe. That directly attacks the exploit precondition — a malicious message surviving until an admin opens Queue Manager — and can be implemented during routine mail hygiene work.
3. Review browser-side controls — Deploy or tighten CSP and related response headers on the admin UI if your mailcow customization path allows it. This is not a guaranteed fix, but it can blunt payload freedom and make admin-session abuse noisier while you move to a patched build.
4. Instrument admin actions — Log and review high-impact admin operations — mailbox creation, relay changes, routing changes, quarantine actions — especially when they occur immediately after queue inspection. There is no mitigation SLA for MEDIUM, but this is worth enabling now because successful exploitation will often masquerade as a legitimate admin session.

Run this on the mailcow host inside the local clone directory, typically cd /opt/mailcow-dockerized && sudo bash ./check-cve-2026-7460.sh. It needs read access to the mailcow Git working tree; root is simplest but not strictly required if the repo is readable.

#!/usr/bin/env bash
# check-cve-2026-7460.sh
# Detect likely exposure to CVE-2026-7460 in mailcow-dockerized.
# Logic:
#   - Vulnerable known release: 2026-03b
#   - Patched train begins at: 2026-05
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_DIR="${1:-.}"
AFFECTED="2026-03b"
PATCHED_MIN="2026-05"

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

if [ ! -d "$TARGET_DIR/.git" ]; then
  fail_unknown "No .git directory found in '$TARGET_DIR'. Run this from the mailcow-dockerized checkout or pass its path as arg 1."
fi

cd "$TARGET_DIR" || fail_unknown "Cannot enter '$TARGET_DIR'."

# Try the exact tag first, then any tag pointing at HEAD.
TAG="$(git describe --tags --exact-match 2>/dev/null || true)"
if [ -z "$TAG" ]; then
  TAG="$(git tag --points-at HEAD | head -n1)"
fi

if [ -z "$TAG" ]; then
  fail_unknown "Could not determine the installed mailcow tag from Git metadata."
fi

normalize_tag() {
  # Converts tags like 2026-05, 2026-05a, 2026-03b into sortable keys YYYYMMsuf
  # suffix: none=0, a=1, b=2, c=3 ... z=26
  local t="$1"
  if [[ ! "$t" =~ ^([0-9]{4})-([0-9]{2})([a-z]?)$ ]]; then
    return 1
  fi
  local year="${BASH_REMATCH[1]}"
  local mon="${BASH_REMATCH[2]}"
  local suf="${BASH_REMATCH[3]}"
  local ord=0
  if [ -n "$suf" ]; then
    ord=$(( $(printf '%d' "'${suf}") - 96 ))
  fi
  printf '%04d%02d%02d' "$year" "$mon" "$ord"
  return 0
}

TAG_N="$(normalize_tag "$TAG" 2>/dev/null || true)"
PATCHED_N="$(normalize_tag "$PATCHED_MIN" 2>/dev/null || true)"

if [ "$TAG" = "$AFFECTED" ]; then
  echo "VULNERABLE: installed tag is $TAG (known affected release for CVE-2026-7460)."
  exit 1
fi

if [ -n "$TAG_N" ] && [ -n "$PATCHED_N" ]; then
  if [ "$TAG_N" -ge "$PATCHED_N" ]; then
    echo "PATCHED: installed tag is $TAG (patched train starts at $PATCHED_MIN)."
    exit 0
  fi
fi

# Older or unrecognized tags are not asserted vulnerable because the advisory only names 2026-03b.
echo "UNKNOWN: installed tag is $TAG; advisory evidence reviewed names $AFFECTED as affected and $PATCHED_MIN+ as patched."
exit 2

Sources

1. Fluid Attacks advisory
2. mailcow official 2026-05 release notes
3. mailcow GitHub releases
4. OpenCVE mailcow product view
5. CISA KEV catalog
6. mailcow documentation
7. Tenable CVE entry
8. SentinelOne CVE entry