In a concerning revelation for cybersecurity, a penetration tester has identified over 20 vulnerabilities in the SFX2100 satellite receiver, a device utilized by the U.S. Department of Defense, the European Space Agency, and other critical infrastructure operators globally. Despite the severity of these findings, the device’s manufacturer, International Data Casting Corporation (IDC), has not responded to any disclosure attempts over several months.
The researcher, whose findings were publicly shared on a recent Thursday, made the discoveries while conducting a routine penetration test for a critical infrastructure client. Initially, the researcher attempted to follow the typical 90-day responsible disclosure protocol, which included reaching out directly to IDC’s president via LinkedIn. After these outreach efforts yielded no response, the researcher felt compelled to move forward with a full public disclosure to ensure awareness of the vulnerabilities.
The identified vulnerabilities represent a broad spectrum of failures commonly found in embedded devices. The vulnerabilities range from hardcoded credentials and unauthenticated remote code execution (RCE) to OS command injection, path traversal, and poorly configured file system permissions. The vulnerabilities have been assigned formal identifiers, categorized as CVEs ranging from CVE-2026-28769 to CVE-2026-29128.
Among the alarming issues, CVE-2026-28775 stands out, permitting any attacker on the network to execute arbitrary commands with root privileges—the highest level of access available—without the need for a username or password. This vulnerability exploits the Simple Network Management Protocol (SNMP), which is typically used for remote device management, alongside a feature that allows administrators to define custom commands. Alarmingly, the SFX2100 was shipped with a default read-write SNMP community string labeled “private,” effectively leaving a significant administrative back door wide open.
The situation is further exacerbated by the device’s credential management. It has been revealed that the device ships with at least four undocumented hardcoded accounts—admin, monitor, user, and xd—all secured with the easily guessable password “12345.” These accounts are not mentioned in IDC’s official documentation, and the researcher uncovered them by examining the password files within the device and utilizing common password-cracking tools. Significantly, all accounts were compromised immediately, highlighting a critical security oversight by IDC.
Another particularly concerning issue is linked to CVE-2026-28778. This vulnerability exploits the “xd” account’s FTP access in conjunction with a root-owned binary residing in a directory fully controlled by the “xd” account. Since the account has permissions to overwrite that binary through FTP, an attacker with access to those credentials—easily obtainable due to the hardcoded nature of the accounts—can substitute the binary with malicious code. While the researcher refrained from exploiting this vulnerability on live systems, the potential implications are alarming for organizations that utilize this technology.
The web management interface of the SFX2100 is not immune to vulnerabilities either. Two separate endpoints were identified that accept user-supplied input and pass it to the underlying operating system for execution without appropriate sanitization—classifying them as OS command injection flaws. This oversight means that an attacker could intercept valid requests and execute arbitrary commands on the device.
Additionally, standard Linux utilities embedded within the device possess misconfigured permissions, allowing any user with low privileges to access sensitive system files, including those containing password hashes. This potentially enables an attacker to conduct offline hash cracking with ease. Furthermore, network routing configurations complicate matters by storing plaintext passwords within files that any user on the system can read. Once again, the password defaults to “12345,” a password known to be highly insecure.
The researcher pointed out that IDC’s various products likely share a common codebase among different models, raising the possibility that these vulnerabilities extend far beyond the SFX2100. For organizations that currently operate IDC hardware in sensitive areas, such as classified or critical infrastructure environments, this poses an urgent necessity for inventory checks and network isolation of affected devices until proper patches are developed.
As of the latest report, IDC has not made any public statements or issued advisories concerning these vulnerabilities. The lack of communication from the manufacturer raises additional concerns about the device’s security posture and the potential risks posed to critical infrastructure operators relying on this technology. The situation highlights a significant gap in cybersecurity practices and the need for manufacturers to prioritize timely communication and remediation efforts in the face of identified vulnerabilities.