International Datacasting Corporation

CVE-2026-28776 is not a memory-corruption bug or a fancy bypass; it is simpler and uglier than that. IDC SFX2100 SuperFlex Satellite Receiver devices ship with an undocumented monitor account that the researcher says accepts monitor:12345 over SSH, and the CVE/CNA record says the attacker lands in a restricted shell that can be trivially escaped to normal shell use. The authoritative CVE record names the affected product as the IDC SFX2100 SuperFlex Satellite Receiver; no trustworthy public source reviewed here provides a clean firmware range or a fixed build, so the safe working assumption is all SFX2100 deployments until the vendor proves otherwise.

The vendor/NVD-style 9.8 score overstates real enterprise urgency because it prices this like an internet-scale, mass-exploitable pre-auth full-compromise bug. In reality, the decisive friction is reachability: an attacker still needs network path to the appliance's SSH service, and these receivers are niche operational/broadcast gear usually sitting on management or private infrastructure networks, not on the open internet at SaaS scale. That said, once reachable, authentication is basically absent, so this is still a HIGH issue for any organization that owns the product.

Why this verdict

• Downgraded for reachability friction: CVSS treats AV:N/PR:N/UI:N as if the box is broadly reachable, but this is a niche receiver commonly placed on private management or operational networks.
• Still high because auth is basically absent: if an attacker can touch SSH, the public disclosure says monitor:12345 gets them in with trivial effort.
• Blast radius is usually local to the appliance: this CVE grants a shell foothold on one receiver, not automatic domain compromise or internet-scale wormability on its own.

Why not higher?

This is not a justified CRITICAL in fleet-priority terms because the exploit chain has a very real first gate: network access to a specialized appliance's SSH service. There is also no strong public signal here of KEV listing, mass scanning, or active exploitation that would override that friction and force an immediate-everywhere response.

Why not lower?

It should not fall to MEDIUM because the authentication bypass is embarrassingly easy once the service is reachable, and the attacker does not need phishing, user interaction, or valid enterprise credentials. On sensitive broadcast/defense-adjacent infrastructure, a shell on the appliance is operationally significant even without root.

1. Block SSH to receivers — Restrict TCP/22 to a tiny admin allowlist or dedicated jump hosts, and deploy this within 30 days because the reassessed verdict is HIGH. This directly kills the decisive prerequisite for exploitation: reachability.
2. Disable or remove the monitor account if operationally safe — If the platform allows account disablement, remove the undocumented credential path and verify no management workflow depends on it; complete this within 30 days. If the vendor will not document account behavior, test on non-production gear first.
3. Segment receiver management networks — Move SFX2100 management access behind VPN, bastion, or out-of-band admin enclaves within 30 days. The point is not abstract hygiene; it is to convert an unauthenticated remote issue into a harder post-access scenario.
4. Alert on monitor SSH authentication — Create detections for any successful login by username monitor and investigate immediately; deploy within 30 days. On appliances like this, a single success is suspicious enough to page a human.
5. Inventory every IDC receiver — Find all SFX2100 and adjacent IDC receiver models within 30 days because the researcher suspects broader code reuse across the line. You cannot prioritize what you have not enumerated.

Run this from an auditor workstation or jump host that can reach the receiver over SSH; example: ./check_cve_2026_28776.sh 10.10.20.15. It needs bash, ssh, and sshpass installed, and no privileges on the target beyond network reachability.

#!/usr/bin/env bash
# Check for CVE-2026-28776 on IDC SFX2100 by testing the disclosed SSH credential.
# Usage: ./check_cve_2026_28776.sh <host> [port]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/dependency error

set -u

HOST="${1:-}"
PORT="${2:-22}"
USER="monitor"
PASS="12345"
TIMEOUT_BIN="timeout"
SSH_BIN="ssh"
SSHPASS_BIN="sshpass"

if [[ -z "$HOST" ]]; then
  echo "UNKNOWN: usage: $0 <host> [port]"
  exit 3
fi

if ! command -v "$SSH_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN: ssh not installed"
  exit 3
fi

if ! command -v "$SSHPASS_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN: sshpass not installed"
  exit 3
fi

if ! command -v "$TIMEOUT_BIN" >/dev/null 2>&1; then
  echo "UNKNOWN: timeout not installed"
  exit 3
fi

SSH_OPTS=(
  -p "$PORT"
  -o StrictHostKeyChecking=no
  -o UserKnownHostsFile=/dev/null
  -o PreferredAuthentications=password
  -o PubkeyAuthentication=no
  -o KbdInteractiveAuthentication=no
  -o ConnectTimeout=8
  -o LogLevel=ERROR
)

# We intentionally run a harmless command. If the restricted shell blocks it but login succeeds,
# OpenSSH typically still returns output/banners indicating successful authentication.
OUT=$("$TIMEOUT_BIN" 15 "$SSHPASS_BIN" -p "$PASS" "$SSH_BIN" "${SSH_OPTS[@]}" "$USER@$HOST" 'echo NG_OK' 2>&1)
RC=$?

if [[ $RC -eq 124 ]]; then
  echo "UNKNOWN: connection timed out"
  exit 2
fi

# Positive hit: command executed, or shell/banner indicates auth success.
if echo "$OUT" | grep -Eq 'NG_OK|Last login|restricted|IDC>|monitor@|\$PATH'; then
  echo "VULNERABLE"
  exit 1
fi

# Common hard-fail auth/network cases.
if echo "$OUT" | grep -Eqi 'Permission denied|Authentication failed|connection refused|No route to host|Network is unreachable|Connection closed by remote host'; then
  # Distinguish auth failure from transport issues.
  if echo "$OUT" | grep -Eqi 'Permission denied|Authentication failed'; then
    echo "PATCHED"
    exit 0
  else
    echo "UNKNOWN"
    exit 2
  fi
fi

echo "UNKNOWN"
exit 2

Sources

1. NVD entry for CVE-2026-28776
2. CVE.org record for CVE-2026-28776
3. Abdul Mhanni disclosure: SFX2100 vulnerabilities
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. The Cyber Express coverage of IDC SFX2100 flaws
7. IDC government/broadcast deployment context