Arbitrary File Write via Path Traversal upload to Remote Code Execution in SeppMail User Web Interface

CVE-2026-2743 is a path traversal in SEPPmail's Large File Transfer (LFT) upload handling inside the user web interface. The vulnerable code path is in file.app, and authoritative records say affected versions are 15.0.2.1 and earlier, with the vendor fix landing in 15.0.3; later research notes the broader hardening landed across the 15.0.4 security rollup as well. The bug lets an attacker control the uploaded file path, escape the session directory, and write attacker-chosen content to writable filesystem locations.

The vendor's CRITICAL 9.8 label is understandable in a lab because the end-state is full appliance takeover and mail visibility on an Internet-facing security gateway. In real fleets, though, this is not a universal unauthenticated smash-and-grab: exploitation depends on the LFT feature path being present, the /v1/file.app route being reachable, and in many deployments obtaining a GINA/LFT-capable session first. Default self-registration keeps this from dropping far, but those deployment frictions are enough to pull it down from CRITICAL to a still-urgent HIGH.

Why this verdict

• Downgraded for feature gating: this is tied to the LFT upload path, so appliances without that license/feature path are out of scope.
• Downgraded for practical access friction: public exploitation examples use an authenticated upload flow; that implies a GINA/LFT-capable session rather than a blind anonymous POST against every Internet-exposed box.
• Not downgraded further because auth is soft in practice: SEPPmail docs show self-registration in the GINA portal is active by default, which materially lowers the barrier to reaching the vulnerable workflow.
• Upward pressure from impact: if the chain lands, the attacker can take over the appliance and access mail traffic, which is a high-value trust boundary failure.
• Upward pressure from exposure shape: this is an edge security appliance/webmail workflow, so when the feature is enabled the reachable population is attacker-friendly even if the overall product population is niche.
• PoC availability matters: there is a detailed public chain to RCE, including the writable target and trigger mechanism, which removes a lot of exploit-development friction.

Why not higher?

Because the vendor baseline assumes a universally reachable unauthenticated network service, and the real attack path is narrower than that. The need for the LFT surface plus a workable GINA/LFT session is a meaningful compound friction point across enterprise deployments.

Why not lower?

Because the downside is not a low-impact authenticated bug in a back-office tool; it is full compromise of a mail security gateway that often sits at a trusted edge position. Default self-registration means the authentication hurdle is weaker than it first appears, so this is still an urgent Internet-edge problem.

1. Disable or unpublish LFT where unused — If the business does not need Large File Transfer, remove the exposed attack surface entirely. For a HIGH verdict, deploy this compensating control within 30 days; if you cannot disable LFT, at least confirm whether /v1/file.app is externally reachable.
2. Constrain GINA self-registration — Tighten or disable self-registration paths and restrict who can create/send new GINA/LFT messages so the practical auth hurdle becomes real instead of nominal. Deploy within 30 days because this directly attacks the easiest precondition in the chain.
3. Restrict edge access to the web UI — Place the SEPPmail user web interface behind source-IP allowlists, VPN, reverse-proxy access control, or equivalent where business usage permits. Do this within 30 days to shrink the remotely reachable population.
4. Monitor integrity of syslog.conf and appliance egress — The public RCE chain relies on overwriting /etc/syslog.conf and then getting code execution or a callback. Add high-signal alerting for unexpected changes to that file and for unusual outbound connections from the appliance within 30 days.
5. Turn on network detection for traversal attempts — If you run Check Point, update IPS and enable the published SEPPMail RCE protection; otherwise add proxy/WAF detections for traversal patterns in JSON upload bodies targeting /v1/file.app. Deploy within 30 days as a detection backstop, not a patch substitute.

Run this on the SEPPmail appliance itself over console or SSH as a local admin user with read access to system files and local HTTPS. Save it as check-cve-2026-2743.sh, then run bash check-cve-2026-2743.sh. It needs no package installs; root is helpful but not strictly required if the version files are world-readable.

#!/usr/bin/env bash
# check-cve-2026-2743.sh
# Purpose: assess likely exposure to CVE-2026-2743 on a SEPPmail appliance
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

CUTOFF_VULN="15.0.2.1"
FIRST_PATCHED="15.0.3"
VERSION=""
ENDPOINT_CODE=""
FOUND_FROM=""

log() { printf '%s\n' "$*"; }

version_le() {
  # returns 0 if $1 <= $2 using version sort
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

version_ge() {
  # returns 0 if $1 >= $2 using version sort
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

extract_version() {
  sed -nE 's/.*\b([0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?)\b.*/\1/p' "$1" 2>/dev/null | head -n1
}

try_file() {
  local f="$1"
  if [ -r "$f" ]; then
    local v
    v="$(extract_version "$f")"
    if [ -n "$v" ]; then
      VERSION="$v"
      FOUND_FROM="$f"
      return 0
    fi
  fi
  return 1
}

# Common candidate files / locations on appliances
for f in \
  /etc/version \
  /etc/seppmail-release \
  /usr/local/etc/seppmail-release \
  /usr/local/share/seppmail/version \
  /root/.version \
  /etc/motd; do
  try_file "$f" && break
done

# Local endpoint reachability probe; harmless HEAD/GET without credentials
if command -v curl >/dev/null 2>&1; then
  ENDPOINT_CODE="$(curl -ksS -o /dev/null -w '%{http_code}' https://127.0.0.1/v1/file.app 2>/dev/null || true)"
  if [ -z "$ENDPOINT_CODE" ] || [ "$ENDPOINT_CODE" = "000" ]; then
    ENDPOINT_CODE="$(curl -ksS -o /dev/null -w '%{http_code}' https://localhost/v1/file.app 2>/dev/null || true)"
  fi
fi

if [ -n "$VERSION" ]; then
  log "Detected version: $VERSION (source: $FOUND_FROM)"
  [ -n "$ENDPOINT_CODE" ] && log "Local /v1/file.app HTTP status: $ENDPOINT_CODE"

  if version_le "$VERSION" "$CUTOFF_VULN"; then
    log "VULNERABLE"
    exit 1
  fi

  if version_ge "$VERSION" "$FIRST_PATCHED"; then
    log "PATCHED"
    exit 0
  fi

  log "UNKNOWN"
  exit 2
fi

# No version found; use endpoint behavior as a weak signal only
if [ -n "$ENDPOINT_CODE" ]; then
  log "Could not determine local SEPPmail version from common files."
  log "Local /v1/file.app HTTP status: $ENDPOINT_CODE"

  case "$ENDPOINT_CODE" in
    404)
      log "PATCHED"
      exit 0
      ;;
    200|401|403)
      log "UNKNOWN"
      exit 2
      ;;
    *)
      log "UNKNOWN"
      exit 2
      ;;
  esac
fi

log "Could not determine version or endpoint status."
log "UNKNOWN"
exit 2

Sources

1. NVD CVE-2026-2743
2. SEPPmail Extended Release Notes 15.0
3. InfoGuard Labs technical write-up
4. SEPPmail GINA settings documentation
5. Check Point IPS advisory CPAI-2026-5100
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. OpenCVE record view