Improper neutralization of special elements in the /IDC_Logging/checkifdone

CVE-2026-28770 is an XML injection flaw in IDC SFX Series SuperFlex Satellite Receiver web management interface version 101. In /IDC_Logging/checkifdone.cgi, the file parameter is copied into the XML response without XML-safe escaping, so an attacker with valid access to the management UI can break XML structure and inject arbitrary elements; the researcher also showed it can be turned into reflected XSS, while XXE remains *possible* rather than demonstrated.

The vendor's 8.8/HIGH overstates real enterprise urgency. The biggest downgrade drivers are practical: it requires authenticated remote access, it lives on a specialized satellite receiver admin interface rather than a mass-exposed enterprise platform, exploitation evidence is absent (KEV: No, very low EPSS), and the strongest downstream impact in public reporting is reflected XSS, not proven device takeover.

Why this verdict

• Start from vendor 8.8, then cut for attacker position: PR:L means the attacker is already authenticated to the appliance management UI. That usually implies prior compromise, stolen creds, or insider access, which is strong downward pressure on urgency.
• Cut again for exposure population: this is a specialized IDC satellite receiver admin interface, not Exchange, VPN, or a mainstream hypervisor. The reachable population in a 10,000-host enterprise is usually tiny even if the technical bug is real.
• Cut for demonstrated impact: public evidence confirms XML injection and reflected XSS, while XXE is described as *possible*. The vendor vector assumes C:H/I:H/A:H, but the public proof does not show reliable loss of all three at that level from this CVE alone.

Why not higher?

There is no KEV listing, no public exploitation evidence, and the attack is not unauthenticated remote. Most importantly, the strongest demonstrated outcome is not appliance takeover but response-format abuse that can be converted into reflected XSS. That's real, but it is not a mass-burn, patch-in-hours event by itself.

Why not lower?

This still sits on an administrative interface of a high-value infrastructure appliance, and authenticated bugs on edge/OT-adjacent gear can matter a lot once an attacker lands. Also, the same product family has adjacent serious weaknesses in public research, so you should not dismiss this entire management plane as harmless just because this specific CVE is narrower.

1. Restrict the management plane — Limit the web UI to a dedicated admin network, jump host, or VPN allowlist. For a MEDIUM verdict there is no mitigation SLA under noisgate, so do this at the next practical network change window and keep it in place until the product is remediated or retired within the 365-day remediation window.
2. Require strong admin authentication — Rotate all local/admin credentials, remove shared accounts where possible, and front the interface with stronger access control if your architecture allows it. This matters because the exploit path starts with authenticated access; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, using this as risk reduction in the meantime.
3. Log and alert on suspicious file parameters — Inspect reverse-proxy, firewall, or local web logs for requests to /IDC_Logging/checkifdone.cgi where file contains XML metacharacters, ]]>, traversal patterns, or oversized encoded input. Tune detections now and keep them active through the remediation period because post-auth appliance exploitation is otherwise easy to miss.
4. Inventory every SFX receiver — Find all IDC SFX devices, confirm whether they run web management interface version 101, and record who can authenticate to them. For a MEDIUM issue, complete the asset-and-access review during the normal remediation cycle, because unknown appliance ownership is what turns manageable bugs into long-lived exposures.

Run this on the SFX appliance itself over SSH or console. Invoke it as sudo bash ./check-cve-2026-28770.sh; it needs read access to the installed CGI files and works best with root because file locations on embedded appliances vary.

#!/usr/bin/env bash
# check-cve-2026-28770.sh
# Detect likely presence of CVE-2026-28770 on IDC SFX appliances.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

CANDIDATES=(
  "/usr/libexec/webmin/IDC_Logging/checkifdone.cgi"
  "/var/www/cgi-bin/IDC_Logging/checkifdone.cgi"
  "/www/cgi-bin/IDC_Logging/checkifdone.cgi"
  "/opt/IDC_Logging/checkifdone.cgi"
)

found=""
for f in "${CANDIDATES[@]}"; do
  if [ -f "$f" ]; then
    found="$f"
    break
  fi
done

if [ -z "$found" ]; then
  found=$(find / -type f -path "*/IDC_Logging/checkifdone.cgi" 2>/dev/null | head -n 1)
fi

if [ -z "$found" ]; then
  echo "UNKNOWN - checkifdone.cgi not found"
  exit 2
fi

# Heuristic 1: vulnerable code reflects unescaped file parameter into XML.
if grep -Eq '<name>\$filegive</name>|<name>\$cgi->param\('\''file'\''\)</name>' "$found"; then
  # Heuristic 2: look for lack of XML escaping helpers on the same file.
  if ! grep -Eqi 'XML::|escapeXML|encode_entities|xml_escape|CGI::escapeHTML' "$found"; then
    echo "VULNERABLE - unescaped file parameter reflected into XML in $found"
    exit 1
  fi
fi

# Secondary check: vulnerable samples also use raw stat() on the supplied file parameter.
if grep -Eq 'stat\(\$workdir \. \$cgi->param\('\''file'\''\)' "$found"; then
  if grep -Eq '<name>\$filegive</name>|<name>\$cgi->param\('\''file'\''\)</name>' "$found"; then
    echo "VULNERABLE - raw file parameter used in filesystem and XML response in $found"
    exit 1
  fi
fi

echo "PATCHED - vulnerable reflection pattern not found in $found"
exit 0

Sources

1. NVD entry for CVE-2026-28770
2. OpenCVE record for CVE-2026-28770
3. Researcher write-up: SFX2100 vulnerabilities
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS data and report documentation
6. IDC SFX Series manual showing Web GUI operation
7. Singapore CSA weekly bulletin mentioning the CVE