Securepoint UTM Fail2Ban IPv6 handling flaw weakens temporary blocking

CVE-2024-41993 affects Securepoint UTM. The vendor says the flaw sits in the product's Fail2Ban handling of IPv6 addresses, causing failed login attempts to not be temporarily blocked as configured. Securepoint lists affected versions as 11.8 through 12.6.5.1 and 12.7.1.3 (Reseller Preview), with a fix in 12.7.2, first published on 2024-08-14.

In practice this is not a direct auth bypass, RCE, or privilege-escalation. It matters only when the appliance has IPv6 configured and the administrator has enabled access to UTM-hosted services over IPv6; then an attacker can keep hammering exposed login surfaces without the expected temporary ban. That makes it real, but narrower than headline appliance bugs: it amplifies brute-force economics rather than delivering compromise by itself.

Why this verdict

• Requires IPv6 exposure: the vendor explicitly says the issue only triggers when IPv6 is configured and UTM-hosted services are enabled for those addresses. That is immediate downward pressure because many deployments either do not expose those paths or do not expose them broadly over IPv6.
• Not a direct compromise primitive: there is no code execution, auth bypass, or privilege escalation in the bug itself. The attacker still needs a second-stage win such as guessed credentials, weak password auth, or another auth weakness.
• Still matters on edge services: when you do expose admin, user, SSH, or VPN-related entry points, losing temporary blocking can materially improve password-spraying odds. On a perimeter appliance, that is more than paper-cut hygiene, so this stays above LOW.

Why not higher?

The attack chain compounds several real-world prerequisites: internet reachability over IPv6, an actually exposed UTM service, password-based authentication worth spraying, and credentials weak enough to crack online. Modern controls such as MFA, client certs, upstream ACLs, and GeoIP/rate limiting break the chain before the CVE alone can create impact.

Why not lower?

This is still a security-control failure on an internet edge product, not a purely theoretical code defect in a dormant library. If an organization relies on temporary banning to slow brute-force traffic on exposed IPv6 services, the bug can change attacker economics enough to deserve planned remediation and exposure review.

1. Shut off unnecessary IPv6 exposure — Remove IPv6 reachability for UTM-hosted services that do not need to be internet-facing, especially admin and SSH paths. For a MEDIUM verdict there is no mitigation SLA, but exposed edge services are worth hardening immediately as part of normal operations while you work toward the 365-day remediation window.
2. Enforce stronger authentication — Require MFA, client certificates, SSH keys, or other non-password controls on exposed services so the missing IPv6 ban does not turn into actual account compromise. There is no mitigation SLA for MEDIUM, so treat this as an opportunistic hardening move now and complete patch remediation within the 365-day window.
3. Rate-limit upstream of the appliance — Use the upstream firewall, reverse proxy, or access edge to rate-limit, allowlist, or GeoIP-restrict management and user-facing services over IPv6. This is the cleanest way to replace the missing brake externally; again, no mitigation SLA applies, but do it now for exposed services and patch within 365 days.
4. Review IPv6 listener inventory — Validate which UTM services actually bind to and accept traffic on global IPv6 addresses, because many teams secure only the IPv4 path and forget the AAAA path. For MEDIUM there is no mitigation SLA, so fold this into your next exposure-review cycle and complete vendor remediation inside the 365-day remediation window.

Run this on the Securepoint UTM itself over SSH as root if possible. Save it as cve-2024-41993-check.sh and run bash cve-2024-41993-check.sh; it needs local shell access and benefits from root privileges so it can query version data, IPv6 addresses, and listening sockets.

#!/usr/bin/env bash
# CVE-2024-41993 Securepoint UTM check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

VERSION=""
RAW_INFO=""

have_cmd() { command -v "$1" >/dev/null 2>&1; }

extract_version() {
  printf '%s\n' "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1
}

# Try a few Securepoint-specific and generic ways to obtain firmware version.
if have_cmd system; then
  RAW_INFO="$(system upgrade info 2>/dev/null)"
  VERSION="$(extract_version "$RAW_INFO")"
fi

if [ -z "$VERSION" ] && have_cmd spcli; then
  RAW_INFO="$(printf 'system upgrade info\n' | spcli 2>/dev/null)"
  VERSION="$(extract_version "$RAW_INFO")"
fi

if [ -z "$VERSION" ] && [ -r /etc/version ]; then
  RAW_INFO="$(cat /etc/version 2>/dev/null)"
  VERSION="$(extract_version "$RAW_INFO")"
fi

if [ -z "$VERSION" ] && [ -r /etc/issue ]; then
  RAW_INFO="$(cat /etc/issue 2>/dev/null)"
  VERSION="$(extract_version "$RAW_INFO")"
fi

if [ -z "$VERSION" ] && [ -r /etc/os-release ]; then
  RAW_INFO="$(cat /etc/os-release 2>/dev/null)"
  VERSION="$(extract_version "$RAW_INFO")"
fi

ver_to_int() {
  # Convert dotted version to zero-padded comparable integer string.
  # Supports up to 4 components.
  local IFS='.'
  local a b c d
  read -r a b c d <<< "$1"
  a=${a:-0}; b=${b:-0}; c=${c:-0}; d=${d:-0}
  printf '%04d%04d%04d%04d\n' "$a" "$b" "$c" "$d"
}

version_ge() { [ "$(ver_to_int "$1")" -ge "$(ver_to_int "$2")" ]; }
version_le() { [ "$(ver_to_int "$1")" -le "$(ver_to_int "$2")" ]; }
version_eq() { [ "$(ver_to_int "$1")" -eq "$(ver_to_int "$2")" ]; }

# Determine runtime preconditions from vendor advisory:
# - IPv6 must be configured
# - Access to UTM services over IPv6 must exist
GLOBAL_IPV6=""
LISTEN_IPV6=""

if have_cmd ip; then
  GLOBAL_IPV6="$(ip -6 addr show scope global up 2>/dev/null | grep -Ev 'fe80|tentative|deprecated' || true)"
fi

if have_cmd ss; then
  LISTEN_IPV6="$(ss -lntup 2>/dev/null | grep -E ':::|\[::\]|tcp6|udp6' || true)"
elif have_cmd netstat; then
  LISTEN_IPV6="$(netstat -lntup 2>/dev/null | grep -E ':::|tcp6|udp6' || true)"
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: could not determine Securepoint UTM firmware version"
  exit 2
fi

# Vendor-affected ranges from advisory:
# vulnerable: 11.8 through 12.6.5.1
# vulnerable: 12.7.1.3 (Reseller Preview)
# fixed: 12.7.2

if version_ge "$VERSION" "12.7.2"; then
  echo "PATCHED: firmware version $VERSION is at or above 12.7.2"
  exit 0
fi

IN_AFFECTED_MAINLINE=0
IN_AFFECTED_PREVIEW=0

if version_ge "$VERSION" "11.8" && version_le "$VERSION" "12.6.5.1"; then
  IN_AFFECTED_MAINLINE=1
fi

if version_eq "$VERSION" "12.7.1.3"; then
  IN_AFFECTED_PREVIEW=1
fi

if [ "$IN_AFFECTED_MAINLINE" -eq 1 ] || [ "$IN_AFFECTED_PREVIEW" -eq 1 ]; then
  if [ -n "$GLOBAL_IPV6" ] && [ -n "$LISTEN_IPV6" ]; then
    echo "VULNERABLE: affected version $VERSION with global IPv6 configured and IPv6 listener(s) present"
    exit 1
  else
    echo "UNKNOWN: affected version $VERSION, but local checks did not confirm both global IPv6 configuration and active IPv6 listeners"
    exit 2
  fi
fi

# Any odd branch between 12.6.5.1 and 12.7.2 that is not explicitly named is left as UNKNOWN.
echo "UNKNOWN: version $VERSION is not explicitly listed by the vendor advisory; verify branch/build against Securepoint release notes"
exit 2

Sources

1. Securepoint advisory for CVE-2024-41993
2. Securepoint UTM changelog showing fix in 12.7.2
3. Securepoint IDS/IPS documentation with Fail2Ban and connection-rate controls
4. Securepoint CLI documentation (`system upgrade info`)
5. CISA Known Exploited Vulnerabilities catalog
6. Official CVE record page
7. Feedly CVE tracker entry