A penetration tester found more than 20 vulnerabilities in a satellite receiver deployed by the U.S. Department of Defense (also referred to as the Department of War), the European Space Agency, and other critical infrastructure operators worldwide — and the device’s manufacturer, International Data Casting Corporation (IDC), did not respond to a single disclosure attempt over several months.

The researcher, who published the findings on Thursday, discovered the flaws in IDC’s SFX2100 satellite receiver during a routine penetration test of a critical infrastructure client. After exhausting the standard 90-day responsible disclosure window — including direct outreach to IDC’s president on LinkedIn — the researcher moved to full public disclosure.

The vulnerability list runs the full gamut of embedded device failures. Hardcoded credentials, unauthenticated remote code execution (RCE), OS command injection, path traversal, and some seriously permissive file system configurations. Twenty CVEs now carry formal identifiers spanning CVE-2026-28769 through CVE-2026-29128.

Also read: Unencrypted Satellite IP Traffic is a Widespread Problem: Researchers

The most alarming flaw is CVE-2026-28775, which allows any attacker on the network to execute arbitrary commands as root — the highest privilege level on the system — without supplying a username or password. The attack exploits SNMP, a protocol used for remote device management, combined with an extension feature that lets administrators define custom commands. IDC shipped the SFX2100 with a default read-write SNMP community string of “private,” essentially leaving the administrative back door unlocked and labeled.

The credential situation compounds the severity. The device ships with at least four undocumented hardcoded accounts — admin, monitor, user, and xd — all protected by the password “12345.” None of these accounts appear in IDC’s official documentation. The researcher found them simply by reading the device’s password files and running them through a common password-cracking tool against a standard dictionary list. Every single one cracked immediately.

Perhaps most striking is CVE-2026-28778, which chains together the “xd” account’s FTP access with a root-owned binary stored inside a directory that “xd” fully controls. Because the account can overwrite that binary via FTP, any attacker with those credentials — which are hardcoded and publicly disclosed — can replace the binary with malicious code and wait for the system to execute it as root. The researcher deliberately stopped short of weaponizing this chain on the live production system.

The web management interface fares no better. Two separate endpoints accept user-supplied input and pass it directly to the underlying operating system without sanitization — a class of flaw called OS command injection. An attacker who intercepts and modifies a legitimate ping or traceroute request can append additional commands using standard shell operators, running anything they choose on the device. The developer’s attempted fix — blocking only the semicolon character — fails because the pipe character “|” achieves the same result.

Also read: India Strengthens Space Cyber Security with New CERT-In and SIA-India Framework

Two standard Linux utilities, /sbin/ip and /bin/date, carry a misconfigured permission bit that allows any low-privileged user to read sensitive system files, including the file that stores all account password hashes. From that point, cracking those hashes offline becomes a straightforward exercise.

Network routing configurations compound the picture further. Files governing BGP and OSPF — routing protocols that control how data flows across large networks — store plaintext passwords in files any user on the system can read. The password, again, is “12345.” BGP manipulation is a known nation-state technique for redirecting internet traffic at scale.

The researcher noted that IDC’s product line likely shares the same codebase across multiple device models, meaning these vulnerabilities almost certainly extend beyond the SFX2100. For organizations operating IDC hardware in classified, government, or critical infrastructure environments, that possibility warrants immediate inventory and network isolation of affected devices until patches become available.

IDC has not issued any public statement or advisory as of publication.