International Datacasting Corporation

CVE-2026-28777 is a hardcoded/trivial credential issue in the International Datacasting Corporation (IDC) SFX2100 Satellite Receiver: an unauthenticated attacker who can reach SSH can log in with the built-in user account using the weak password 12345, then break out from the restricted shell into a normal interactive session. NVD maps the issue to datacast:sfx2100_firmware and datacast:sfx2100 CPEs, but no narrower affected firmware range or fixed release has been published, so defenders should assume the exposed SFX2100 fleet is affected until proven otherwise.

The vendor/NVD 9.8 is too hot for real patch triage because it scores the flaw in a vacuum. In practice, the decisive friction is *reachability*: this is only exploitable where SSH on a specialized satellite receiver is reachable from the attacker position, and most enterprise/OT deployments put that management plane on private or segmented networks; that keeps this out of CRITICAL for fleet-wide prioritization even though the credential itself is embarrassingly weak.

Why this verdict

• Start from 9.8, then cut for reachability: vendor scoring assumes any remote attacker can touch the service; in the real world this requires SSH exposure or prior network presence on a management/OT segment, so I take roughly -1.0 off the baseline.
• Cut again for blast radius: this CVE lands you on a single niche appliance, not an identity provider, VPN concentrator, or ubiquitous server tier. That narrows enterprise-wide impact even if the local device importance is high, worth about -0.4.
• Add back for ease and reliability: if reachable, the attack is basically ssh user@host with a known trivial password and no exploit chain. That automatable simplicity keeps it solidly HIGH instead of drifting into MEDIUM.

Why not higher?

This is not a mass-market edge product with broad default internet exposure, and the exploit path depends on the management plane being reachable from the attacker's vantage point. Also, the CVE itself grants a user-level foothold on the appliance rather than proven root compromise by itself, so CRITICAL is too aggressive for fleet prioritization.

Why not lower?

MEDIUM would understate the danger where these boxes are reachable, because the attacker needs no prior credentials, no user interaction, and no exploit development. A hardcoded/trivial SSH login on a sensitive infrastructure appliance is still an immediate foothold and should not be treated as routine backlog noise.

1. Restrict SSH to jump hosts — Limit TCP/22 on every SFX2100 to a dedicated management VLAN, VPN concentrator, or hardened bastion and deploy that control within 30 days. This directly removes the main amplifier for the CVE: attacker reachability.
2. Rotate or disable the built-in account — Change the user account password everywhere or lock/disable the account if operations allow, and finish that within 30 days. This neutralizes the credential-abuse path even if the firmware remains vulnerable.
3. Disable SSH where unnecessary — If the receiver can be managed through safer out-of-band paths or tightly-controlled alternatives, turn off SSH and complete the change within 30 days. Removing the service is cleaner than trying to detect every brute-force or reuse attempt.
4. Alert on successful SSH logins — Forward auth logs if possible, or at minimum collect network telemetry for successful SSH sessions into the receiver fleet and stand up alerts within 30 days. On embedded appliances without EDR, auth and network logs are your best evidence source.

Run this on the SFX2100 itself from a root shell or equivalent maintenance shell, because it needs read access to /etc/shadow. Save it as check-cve-2026-28777.sh, then run sudo bash check-cve-2026-28777.sh; it checks whether the user or usr account exists and whether its password still matches 12345.

#!/usr/bin/env bash
# check-cve-2026-28777.sh
# Determine whether IDC SFX2100 is vulnerable to CVE-2026-28777
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/runtime error, 3=UNKNOWN/insufficient privileges

set -u

if [[ ! -r /etc/shadow ]]; then
  echo "UNKNOWN"
  echo "Reason: need read access to /etc/shadow (run as root)." >&2
  exit 3
fi

if ! command -v perl >/dev/null 2>&1; then
  echo "UNKNOWN"
  echo "Reason: perl is required to verify the shadow hash." >&2
  exit 2
fi

check_account() {
  local acct="$1"
  local shadow_line hash result

  shadow_line=$(grep -E "^${acct}:" /etc/shadow 2>/dev/null | head -n1 || true)
  if [[ -z "$shadow_line" ]]; then
    return 10
  fi

  hash=$(printf '%s' "$shadow_line" | cut -d: -f2)

  # Locked / disabled / empty password states count as not vulnerable to this CVE path.
  if [[ -z "$hash" || "$hash" == '!' || "$hash" == '*' || "$hash" == '!!' || "$hash" == '!*' ]]; then
    return 20
  fi

  result=$(perl -e 'my ($pw,$h)=@ARGV; print crypt($pw,$h) eq $h ? "MATCH" : "NO";' '12345' "$hash" 2>/dev/null)
  if [[ "$result" == "MATCH" ]]; then
    return 30
  fi

  return 20
}

found_any=0
for acct in user usr; do
  if grep -q -E "^${acct}:" /etc/passwd 2>/dev/null; then
    found_any=1
    check_account "$acct"
    rc=$?
    if [[ $rc -eq 30 ]]; then
      echo "VULNERABLE"
      echo "Reason: account '$acct' exists and still accepts password 12345." >&2
      exit 1
    fi
  fi
done

if [[ $found_any -eq 0 ]]; then
  echo "PATCHED"
  echo "Reason: no 'user' or 'usr' account present." >&2
  exit 0
fi

echo "PATCHED"
echo "Reason: built-in account exists but password no longer matches 12345, or account is locked." >&2
exit 0

Sources

1. NVD CVE-2026-28777
2. Abdul Mhanni disclosure: 20+ vulnerabilities found in satellite receiver
3. CISA Known Exploited Vulnerabilities Catalog
4. OpenCVE record for CVE-2026-28777
5. SRA/SFX2100 Series User Manual
6. Cyber Express coverage of the SFX2100 vulnerability set
7. CVE Details entry for CVE-2026-28777