SEPPmail Secure Email Gateway before version 15

CVE-2026-7864 affects SEPPmail Secure Email Gateway before 15.0.4 in the new GINA UI. An unauthenticated request to GET /api.app/hello?op=env can return the server's environment variables, exposing system-level runtime details such as paths, hostnames, proxy settings, library locations, and potentially deployment-specific secrets if operators or code placed them there.

In practice, this is not a full compromise bug; it is a pre-auth internet-reachable information leak on an email gateway that often lives on the edge. That keeps it above LOW, but the impact is still materially below RCE or arbitrary file-read because the attacker only gets whatever the environment happens to contain, and many deployments will leak useful recon but not immediately weaponizable credentials.

Why this verdict

• Pre-auth remote, but disclosure-only: no attacker position, auth, or user interaction is required, which pushes severity up from backlog noise.
• Reachable population is real: InfoGuard reports several thousand public SEPPmail instances on Censys, so this is not a lab-only management bug hidden on an internal subnet.
• Impact narrows hard at the last mile: the attacker gets environment variables, and what that means in practice varies wildly by deployment; many systems will leak recon value, not immediate compromise material.
• Modern controls can meaningfully reduce exposure: reverse-proxy ACLs, WAF path rules, VPN-gating, or simple upstream path blocks are credible friction here, unlike a protocol-level RCE that ignores the front door.
• No active-exploitation pressure: low EPSS, no KEV listing, and no public campaign evidence remove the urgency amplifier that would otherwise push this toward HIGH.

Why not higher?

This CVE does not directly provide mail access, arbitrary file read, code execution, integrity loss, or service disruption. To turn it into something bigger, the attacker usually needs either sensitive values in the environment or another weakness to chain, and that dependency is the core downward pressure on severity.

Why not lower?

Calling this LOW would underrate the fact that it is unauthenticated, remotely reachable, and placed on a security gateway that often faces the internet. Even 'just recon' on a mail edge appliance can materially accelerate follow-on attacks, especially when the disclosed data touches proxying, paths, hostnames, or adjacent identity and mail systems.

1. Restrict GINA exposure — Put the GINA/API surface behind partner allowlists, VPN, or reverse-proxy ACLs so unauthenticated internet users cannot hit it directly. For a MEDIUM verdict there is no mitigation SLA, but this is still the cleanest temporary risk reduction when you cannot patch immediately.
2. Block the debug path upstream — Add a reverse-proxy or WAF rule for /api.app/hello and specifically requests containing op=env. For a MEDIUM verdict there is no mitigation SLA, but this is a fast control that directly cuts off exploitation without needing appliance internals.
3. Hunt for prior probing — Search web logs and proxy telemetry for GET /api.app/hello?op=env, close variants, and high-rate enumeration against /api.app. Do this during the same change window you use for validation so you know whether the bug was merely present or actually touched.
4. Review environment hygiene — Audit whether secrets, tokens, or privileged service configuration are being exposed through process environment on the appliance or surrounding reverse-proxy stack. This reduces the blast radius even if a similar debug exposure appears again.

Run this from an auditor workstation or jump host that can reach the SEPPmail HTTPS interface; it does not need shell access on the appliance. Invoke it as ./check-seppmail-cve-2026-7864.sh https://mail-gateway.example.com and no special privileges are required beyond network access.

#!/usr/bin/env bash
# check-seppmail-cve-2026-7864.sh
# Detect likely exposure of CVE-2026-7864 by probing the unauthenticated debug path.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

if [ $# -ne 1 ]; then
  echo "UNKNOWN - usage: $0 https://seppmail.example.com"
  exit 2
fi

BASE_URL="$1"
BASE_URL="${BASE_URL%/}"
TARGET_URL="${BASE_URL}/api.app/hello?op=env"

TMPFILE="$(mktemp 2>/dev/null || echo /tmp/seppmail-cve-2026-7864.$$)"
cleanup() {
  rm -f "$TMPFILE" >/dev/null 2>&1 || true
}
trap cleanup EXIT

HTTP_CODE="$(curl -k -sS --max-time 15 -o "$TMPFILE" -w '%{http_code}' "$TARGET_URL" 2>/dev/null)"
CURL_RC=$?

if [ $CURL_RC -ne 0 ]; then
  echo "UNKNOWN - request failed for ${TARGET_URL}"
  exit 2
fi

# Common patched / blocked outcomes.
case "$HTTP_CODE" in
  401|403|404)
    echo "PATCHED - endpoint blocked, removed, or requires auth (HTTP ${HTTP_CODE})"
    exit 0
    ;;
esac

# Heuristic for environment-variable leakage.
# We intentionally look for multiple common env names to avoid false positives.
if [ "$HTTP_CODE" = "200" ] && grep -Eiq '(^|[^A-Z0-9_])(PATH|HOME|PWD|USER|SHELL|LANG|HTTP_HOST|SERVER_NAME|SERVER_PORT|LD_LIBRARY_PATH|PERL5LIB)=' "$TMPFILE"; then
  echo "VULNERABLE - unauthenticated environment variable disclosure detected at ${TARGET_URL}"
  exit 1
fi

# If the endpoint responds 200 but without obvious env output, the result is ambiguous.
if [ "$HTTP_CODE" = "200" ]; then
  echo "UNKNOWN - endpoint reachable but no clear environment dump matched; inspect response manually"
  exit 2
fi

echo "UNKNOWN - unexpected HTTP status ${HTTP_CODE} from ${TARGET_URL}"
exit 2

Sources

1. NVD CVE-2026-7864
2. InfoGuard Labs technical write-up
3. CISA Known Exploited Vulnerabilities Catalog
4. Check Point IPS advisory CPAI-2026-5101
5. SEPPmail status notice on vulnerabilities and fixes
6. SEPPmail information notices
7. SEPPmail documentation - System
8. SEPPmail documentation - Security