SEPPmail Secure Email Gateway before version 15

CVE-2026-44128 is an unauthenticated remote code execution flaw in SEPPmail Secure Email Gateway before 15.0.2.1. The vulnerable path sits in the new GINA v2 UI under /api.app/template, where attacker-controlled input from the upldd parameter is fed into Perl eval, allowing arbitrary Perl execution over HTTPS with no valid session required. InfoGuard's write-up says GINA v2 has been available since roughly January 2025 and requires explicit activation in system settings, which sharply narrows the exposed population compared with the whole SEPPmail install base.

In pure technical terms this is bad enough to look like a CRITICAL: it's pre-auth, remote, low-complexity code execution on an internet-facing email appliance. In real enterprise patch triage, though, the decisive friction is feature-gated exposure: the bug only exists where GINA v2 is enabled and reachable, and the code reportedly runs as the webserver user rather than instant root. That keeps the real-world priority at = ASSESSED AT HIGH rather than CRITICAL, while still making it urgent anywhere GINA v2 is externally exposed.

Why this verdict

• Unauthenticated remote code execution keeps the floor high: the attacker position is unauthenticated remote, which implies true perimeter risk rather than post-compromise abuse.
• GINA v2 is the main downward adjustment: this prerequisite implies a narrower exposed population because the vulnerable UI is newer and requires explicit activation, so the reachable estate is meaningfully smaller than 'all SEPPmail'.
• Blast radius is serious even without instant root: attacker code runs on a mail gateway, a trusted choke point with visibility into message flow and adjacency to internal systems, so a nobody foothold is still operationally dangerous.
• Low exploitation pressure trims the score a bit: EPSS is low, there is no KEV entry, and I found no confirmed live campaigns, which argues against maximum emergency treatment for every org regardless of exposure.

Why not higher?

I am not calling this CRITICAL because the attack chain has a real gating condition: GINA v2 must be enabled and reachable. That prerequisite narrows the exploitable population, and the available research suggests execution lands in a restricted web-process context rather than guaranteed full appliance takeover from this CVE alone.

Why not lower?

I am not dropping this to MEDIUM because the attacker does not need credentials, user interaction, or prior foothold. If your gateway exposes the vulnerable GINA v2 path, this is one HTTP request away from code execution on a security-sensitive perimeter system.

1. Disable GINA v2 where unused — If the business does not actively need the new GINA v2 interface, turn it off and remove the vulnerable attack surface entirely. For a HIGH verdict, deploy this compensating control within 30 days, and faster for any internet-exposed gateway.
2. Restrict web access to /api.app — Put the GINA/API surface behind VPN, IP allowlists, reverse-proxy ACLs, or equivalent edge controls so random internet sources cannot reach it. This is the single best exposure reducer short of patching, and for HIGH should be in place within 30 days.
3. Enable IPS or WAF signatures — Apply available HTTP-layer protections that can detect or block exploit attempts against SEPPmail RCE patterns; Check Point published coverage on 2026-05-20. Treat this as a short-term shield, not a substitute for upgrading, and deploy within 30 days.
4. Increase gateway monitoring — Turn on or forward SEPPmail web logs, proxy logs, and network telemetry so POSTs to /api.app/template, suspicious multipart requests, shelling behavior, and new outbound connections from the appliance are visible. For HIGH, get this visibility uplift done within 30 days.
5. Segment the appliance hard — Constrain the gateway's east-west reach and outbound internet access so a web-process foothold cannot pivot freely or beacon out. This reduces post-exploitation blast radius and should be tightened within 30 days where practical.

Run this on the target SEPPmail appliance over SSH if you can read local files, or from an auditor workstation if you already know the version shown in Home -> Firmware version. Invoke it as bash check_cve_2026_44128.sh 15.0.2.0 or just bash check_cve_2026_44128.sh on-box; local auto-detection uses read-only file access and does not require root if the version files are world-readable.

#!/usr/bin/env bash
# check_cve_2026_44128.sh
# Determine whether a SEPPmail Secure Email Gateway version is vulnerable to CVE-2026-44128.
# Vulnerable: versions earlier than 15.0.2.1
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_FIXED="15.0.2.1"
INPUT_VERSION="${1:-}"
DETECTED_VERSION=""

trim() {
  local s="$1"
  s="${s#${s%%[![:space:]]*}}"
  s="${s%${s##*[![:space:]]}}"
  printf '%s' "$s"
}

extract_version() {
  # Pull the first thing that looks like N.N.N or N.N.N.N
  printf '%s' "$1" | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?' | head -n1 || true
}

version_lt() {
  # returns 0 if $1 < $2
  local a="$1" b="$2"
  local first
  first=$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)
  [[ "$a" != "$b" && "$first" == "$a" ]]
}

try_detect_local() {
  local candidates=(
    "/etc/version"
    "/etc/seppmail-version"
    "/usr/local/etc/version"
    "/usr/local/seppmail/version"
    "/etc/motd"
  )
  local f raw ver

  for f in "${candidates[@]}"; do
    if [[ -r "$f" ]]; then
      raw=$(head -n 5 "$f" 2>/dev/null || true)
      ver=$(extract_version "$raw")
      if [[ -n "$ver" ]]; then
        printf '%s' "$ver"
        return 0
      fi
    fi
  done

  if command -v uname >/dev/null 2>&1; then
    raw=$(uname -a 2>/dev/null || true)
    ver=$(extract_version "$raw")
    if [[ -n "$ver" ]]; then
      printf '%s' "$ver"
      return 0
    fi
  fi

  return 1
}

if [[ -n "$INPUT_VERSION" ]]; then
  DETECTED_VERSION=$(extract_version "$INPUT_VERSION")
else
  DETECTED_VERSION=$(try_detect_local || true)
fi

DETECTED_VERSION=$(trim "$DETECTED_VERSION")

if [[ -z "$DETECTED_VERSION" ]]; then
  echo "UNKNOWN"
  exit 2
fi

if version_lt "$DETECTED_VERSION" "$TARGET_FIXED"; then
  echo "VULNERABLE"
  exit 1
fi

echo "PATCHED"
exit 0

Sources

1. NVD CVE-2026-44128
2. SEPPmail 15.0 release notes
3. InfoGuard Labs technical write-up
4. SEPPmail documentation: securing the gateway
5. SEPPmail documentation: home / firmware version
6. Check Point IPS advisory
7. CISA Known Exploited Vulnerabilities catalog
8. Swiss NCSC CVE list entry