International Datacasting Corporation

CVE-2026-28778 is a chained flaw in IDC's SFX2100/SFX Series SuperFlex satellite receiver: an undocumented xd account can authenticate over FTP, and that account can write into a directory holding XDTerminal plus symlinks later invoked by root-owned paths such as xdstartstop. Public CVE records currently bound the affected product to IDC SFX2100 SuperFlex Satellite Receiver, while NVD's wording says SFX Series; there is still no authoritative public version boundary beyond that model-level identification.

The vendor/NVD 9.8 score overstates enterprise urgency a bit because CVSS assumes raw network reachability and ignores deployment reality. In practice this is a management-plane appliance issue on a niche OT/satellite device, often on segmented or provider-managed networks, and the final root execution depends on both FTP reachability and a root execution path already wired to the attacker-controlled location. Still, if you do expose one of these boxes to a shared or reachable network, the exploit path is short and ugly enough to keep this firmly in HIGH.

Why this verdict

• Downgrade for attacker position: despite AV:N/PR:N, the attacker still needs direct reachability to a niche appliance's FTP/management plane; that usually implies internal, provider, or explicitly exposed management access rather than internet-wide sprayability.
• Downgrade for population size: SFX2100 receivers are specialized satellite/OT gear, not ubiquitous Windows/Linux estate software. Even large enterprises may have zero of them, so the vendor 9.8 does not translate into fleet-wide emergency pressure.
• Downgrade for chain friction: the bug is not pure instant RCE on first packet; it abuses FTP access plus writable paths that are later executed by root. That extra dependency is meaningful downward pressure compared with single-request auth bypasses or direct memory-corruption RCEs.
• Keep it HIGH because exploitation is still easy once reachable: hardcoded creds are public, FTP access is simple, and the privilege boundary after login is weak enough that an exposed box is very plausibly root-compromisable.
• Keep it HIGH because blast radius on the device is total: success yields root on a critical infrastructure receiver, so impact on the affected asset is complete even if the exposed population is small.

Why not higher?

This is not broad, internet-default, one-shot enterprise software exploitation. The attacker generally needs access to a narrow management surface on a niche appliance, and the final root code execution depends on a root invocation path tied to attacker-writable files, which is more friction than direct pre-auth RCE. Those two facts are enough to keep it below CRITICAL.

Why not lower?

Once an attacker can reach FTP on the box, the chain is practical and damaging, not theoretical. Published hardcoded credentials plus weak filesystem boundaries on a root-adjacent execution path create a very credible compromise route to full device takeover, so calling this MEDIUM would understate the consequence for any actually exposed receiver.

1. Block FTP to the device — Shut off the initial foothold by disabling FTP on the receiver if operationally possible, or enforce network ACLs so only tightly controlled admin sources can reach it. For a HIGH verdict, deploy this compensating control within 30 days.
2. Isolate the management plane — Move SFX2100 management access behind VPN, bastion, jump host, or dedicated admin VLANs and remove direct reachability from shared enterprise segments. This reduces the biggest real-world risk multiplier and should be completed within 30 days.
3. Correct ownership and permissions — If you can safely modify the appliance, remove owner-write from directories and files in the xd execution path and break root-owned symlinks that point into attacker-writable locations. This directly severs the privilege-escalation leg and belongs in the 30-day mitigation window.
4. Watch for legacy auth and file tampering — Alert on any FTP authentication to these appliances and any change to /home/xd, /home/monitor, XDTerminal, or xdstartstop-related paths. Use this as a detective backstop while you work through the 180-day remediation window.

Run this on the receiver itself over console or a trusted administrative shell. Invoke it as sudo bash ./check-cve-2026-28778.sh; root is recommended because the script inspects account, symlink, mount, and permission state. It outputs VULNERABLE, PATCHED, or UNKNOWN and exits 0, 1, or 2 respectively.

#!/usr/bin/env bash
# check-cve-2026-28778.sh
# Detect likely vulnerable state for CVE-2026-28778 on IDC SFX2100/SFX Series receivers.
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -u

PASSWD_FILE="/etc/passwd"
FTP_LISTEN=0
HAS_XD=0
XD_HOME=""
XD_SHELL=""
PATH1="/home/xd/terminal/XDTerminal"
PATH2="/home/monitor/xdstartstop"
PATH3="/home/monitor/XDStartStop"
ROOTLINK_OK=0
XD_OWNER_WRITABLE=0
UNKNOWN_REASON=""

say() { printf '%s\n' "$1"; }

# Check xd account
if [ -r "$PASSWD_FILE" ]; then
  xd_line=$(grep '^xd:' "$PASSWD_FILE" 2>/dev/null || true)
  if [ -n "$xd_line" ]; then
    HAS_XD=1
    XD_HOME=$(printf '%s' "$xd_line" | awk -F: '{print $6}')
    XD_SHELL=$(printf '%s' "$xd_line" | awk -F: '{print $7}')
  fi
else
  UNKNOWN_REASON="cannot read /etc/passwd"
fi

# Check whether FTP appears enabled/listening
if command -v ss >/dev/null 2>&1; then
  if ss -lntp 2>/dev/null | grep -Eq '(:21\s)'; then
    FTP_LISTEN=1
  fi
elif command -v netstat >/dev/null 2>&1; then
  if netstat -lnt 2>/dev/null | grep -Eq '[:.]21\s'; then
    FTP_LISTEN=1
  fi
fi

# Fallback config checks if socket tools fail
if [ "$FTP_LISTEN" -eq 0 ]; then
  if [ -f /etc/vsftpd/vsftpd.conf ] || [ -f /etc/vsftpd.conf ] || [ -x /usr/sbin/vsftpd ] || [ -x /usr/local/sbin/vsftpd ]; then
    FTP_LISTEN=1
  fi
fi

# Check symlink chain into xd-owned location
check_link_target() {
  local p="$1"
  [ -L "$p" ] || return 1
  local t
  t=$(readlink "$p" 2>/dev/null || true)
  [ "$t" = "/home/xd/terminal/XDTerminal" ] && return 0
  return 1
}

if check_link_target "$PATH2" || check_link_target "$PATH3"; then
  ROOTLINK_OK=1
fi

# Check whether xd-controlled directory is owner-writable and owned by xd/uid 622 if possible
check_owner_writable() {
  local p="$1"
  [ -e "$p" ] || return 1
  local dir owner mode
  dir=$(dirname "$p")
  if command -v stat >/dev/null 2>&1; then
    owner=$(stat -c '%U' "$dir" 2>/dev/null || true)
    mode=$(stat -c '%A' "$dir" 2>/dev/null || true)
    # owner-writable if third char in rwx triplet is w for owner
    printf '%s' "$mode" | grep -q '^d..w' || printf '%s' "$mode" | cut -c3 | grep -q 'w' || true
    if [ "$owner" = "xd" ] || [ "$owner" = "622" ]; then
      if [ -w "$dir" ]; then
        return 0
      fi
    fi
  fi
  return 1
}

if check_owner_writable "$PATH1"; then
  XD_OWNER_WRITABLE=1
fi

# Decision logic
if [ "$HAS_XD" -eq 1 ] && [ "$FTP_LISTEN" -eq 1 ] && [ "$ROOTLINK_OK" -eq 1 ] && [ "$XD_OWNER_WRITABLE" -eq 1 ]; then
  say "VULNERABLE"
  exit 0
fi

# Strong patched indicators
if [ "$HAS_XD" -eq 0 ]; then
  say "PATCHED"
  exit 1
fi

if [ "$HAS_XD" -eq 1 ] && [ "$FTP_LISTEN" -eq 0 ] && [ "$ROOTLINK_OK" -eq 0 ]; then
  say "PATCHED"
  exit 1
fi

if [ "$HAS_XD" -eq 1 ] && [ "$ROOTLINK_OK" -eq 1 ] && [ "$XD_OWNER_WRITABLE" -eq 0 ] && [ "$FTP_LISTEN" -eq 0 ]; then
  say "PATCHED"
  exit 1
fi

say "UNKNOWN"
if [ -n "$UNKNOWN_REASON" ]; then
  say "$UNKNOWN_REASON" >&2
fi
exit 2

Sources

1. NVD CVE-2026-28778
2. Abdul Mhanni research write-up
3. OpenCVE record for CVE-2026-28778
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. Tenable CVE page
7. The Cyber Express coverage of the IDC disclosures