CVE-2026-2743 · SEPPmail User Web Interface Arbitrary File Write to RCE

01 · The Real Story

This is a loading dock door left open on the mailroom, not a skeleton key to every building

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.

"Internet-reachable gateway takeover, but the blast radius is narrowed by feature/license exposure and a practical auth hurdle."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the LFT upload surface with curl or a browser client

The exposed surface is /v1/file.app, the back-end used for chunked LFT uploads and Outlook add-in bypass uploads. In public write-ups, the request includes Authorization: Basic, so the practical attack is against a reachable LFT/GINA workflow rather than a raw no-session endpoint.

Conditions required:

SEPPmail appliance is Internet-reachable
LFT is licensed/enabled so /v1/file.app exists
Attacker can obtain or create a usable GINA/LFT session; default self-registration materially lowers this bar

Where this breaks in practice:

Not every SEPPmail deployment uses LFT
Some deployments restrict GINA write-new-mail behavior or recipient scope
If /v1/file.app returns 404, this chain is dead

Detection/coverage: Exposure scanners can safely probe https://<host>/v1/file.app; 404 strongly suggests the vulnerable feature path is absent. WAF/IPS coverage exists in Check Point IPS as SEPPMail Secure Email Gateway Remote Code Execution.

STEP 02

Abuse path traversal in the file JSON field

InfoGuard showed the attacker-controlled file parameter is passed into attachment storage without sanitization, so ../ sequences escape the intended session directory. A crafted chunked upload can then overwrite files writable by the web process (nobody).

Conditions required:

Ability to submit a chunked upload to file.app
Target runs a vulnerable build at or below 15.0.2.1

Where this breaks in practice:

The write runs as nobody, so arbitrary write targets are limited
The exploit needs a writable path that can be turned into code execution, not just any file overwrite

Detection/coverage: Signature-based detection is possible on traversal sequences in JSON upload requests. Reverse proxies and HTTP logs should show suspicious ../ patterns in file values if they capture request bodies.

STEP 03

Overwrite /etc/syslog.conf with a command pipe payload

The public exploit chain uses the unusual fact that nobody can write /etc/syslog.conf on the appliance. OpenBSD syslogd supports piping log messages to a command, so replacing that config turns a file-write bug into code execution.

Conditions required:

nobody retains write access to /etc/syslog.conf on the target build
Attacker can fully control uploaded file contents

Where this breaks in practice:

This is appliance-specific post-write engineering, not a generic file-write-to-RCE shortcut
If filesystem permissions or local hardening differ from researched builds, the chain can fail

Detection/coverage: File integrity monitoring on /etc/syslog.conf is high-signal. EDR coverage is often weak on virtual appliances, which is exactly why this step is dangerous.

STEP 04

Trigger syslogd reload via newsyslog and receive shell

The exploit does not immediately execute on write; it waits for syslogd to reload configuration. InfoGuard showed newsyslog runs every 15 minutes and can be forced by bloating log files with web requests, after which the malicious pipe executes and returns a shell.

Conditions required:

newsyslog cron behavior is intact
Attacker can generate enough log activity to force rotation/reload
Outbound connectivity from the appliance supports the chosen payload or an alternative local execution path

Where this breaks in practice:

There is a timing component; this is not always instant
Egress controls can break the public reverse-shell PoC even if code execution is achieved

Detection/coverage: Look for unexpected edits to /etc/syslog.conf, abnormal log growth, newsyslog-adjacent shell spawns, and unusual outbound connections from the SEPPmail appliance.

03 · Compensating Control

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.

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.

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.

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.

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.

What doesn't work

Mailbox-layer email filtering does not help; the exploit lands on the gateway's own web upload path, not via a malicious inbound message to be scanned.
Relying on low EPSS alone is a trap; EPSS reflects broad exploitation probability, not the business impact of a trusted edge appliance takeover.
Assuming 'it needs auth' is enough is weak logic here because default self-registration reduces that barrier substantially.
Endpoint EDR assumptions often fail on hardened virtual appliances, so do not count on process-child alerts to be your primary control.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No confirmed in-the-wild exploitation found in the sources reviewed; not present in the current CISA KEV catalog.
Proof-of-concept availability	Public exploit details exist. InfoGuard Labs published a working attack chain; CISA ADP metadata surfaced by OpenCVE marks exploitation evidence as `poc`.
EPSS	0.00158 (0.158%) from the prompt. That is low on absolute probability, which is consistent with a niche product and no broad exploitation signal.
KEV status	Not KEV-listed. Disclosure was 2026-03-05; no CISA KEV entry was observed during reassessment.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — technically this says straight Internet RCE with no auth. Reality is messier because the practical path commonly rides the LFT/GINA workflow and feature exposure.
Affected versions	Authoritative records say SEPPmail 15.0.2.1 and earlier are affected in the LFT user web interface path.
Fixed version	Vendor release notes show 15.0.3 closes CVE-2026-2743; later 15.0.4/hotfix lines include additional security cleanup in adjacent web components.
Exposure and scan data	InfoGuard states there are several thousand public instances on Censys and that the majority of customers appear to have LFT enabled based on their scan. Treat that as credible third-party exposure intelligence, not independently verified census data here.
Authentication reality	SEPPmail documentation says `Allow account self-registration in GINA portal without initial mail` is active by default. That is the single biggest reason this stays HIGH instead of dropping further despite the feature/license caveat.
Researchers / reporting	Reported by Manuel Feifel and Dario Weiss of InfoGuard Labs; the longer technical post is by Dario Weiss, Manuel Feifel, and Olivier Becker.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (8.4/10)

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.

06 · Verification

Crowdsourced verification payload.

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.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/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