
SatBleed: Security of Commoditized Communication Modules in Satellites
SatBleed is an arXiv paper presenting the first in-depth security evaluation of commercial off-the-shelf (COTS) Communication Subsystem (COM) modules used in small satellites. The authors build a threat taxonomy for COM-targeting attacks, analyze representative COM hardware from multiple vendors, and uncover severe firmware, protocol, and architectural vulnerabilities. By correlating findings with open-source telemetry data, they identify at least 28 vulnerable missions currently in orbit that are susceptible to hostile takeover via their command-and-control link.
What it is
SatBleed is a specific vulnerability class disclosed in the paper, found in a widely-used commercial off-the-shelf (COTS) satellite Communication Subsystem (COM) module. The flaw allows an unauthenticated attacker to extract cryptographic material from ground stations by imitating a satellite — i.e., the attack targets the ground-station side (Front End Processor) of the TT&C link, not just the spacecraft. The paper also introduces a companion tool, SyncWordFuzzer, a physical-layer fuzzer that triggers bugs in sync-word detection within COM modules; code is published at the paper's linked GitHub repo (EmsecCispa/SatBleed).
How it works
The COM subsystem acts as the sole uplink/downlink gateway and is implicitly trusted as the perimeter guard for the entire satellite platform. SatBleed exploits a flaw where the ground station's Front End Processor (FEP) — which shares the same COM hardware/firmware family used on the satellite — can be tricked by a device spoofing a legitimate satellite into leaking cryptographic key material, with no authentication required to trigger the leak. Separately, SyncWordFuzzer operates at the physical layer, fuzzing sync-word detection logic to surface implementation bugs in COM firmware.
Preconditions / Affected
The vulnerability is tied to a specific widely-deployed COTS COM module family (vendor/model not disclosed in the fetched excerpt) used across "over one hundred missions." Exploitation requires the ability to transmit RF signals that imitate a satellite to a ground station's FEP running the vulnerable module. The 28 missions identified as susceptible to full takeover are derived by cross-referencing SatNOGS telemetry with this and other vulnerabilities found in the study — SatBleed itself (the credential-extraction bug) is one entry in that broader finding set, not necessarily the sole cause of all 28 cases.
What to do
The excerpt does not include patch versions, CVE identifiers, or vendor-specific remediation steps. The authors state they derive "architectural recommendations to improve resilience" but the fetched text does not enumerate them. The one concrete artifact provided is the fuzzer itself, usable for testing COM firmware sync-word handling:
https://github.com/EmsecCispa/SatBleedCaveats
The vendor/product name, affected firmware versions, and the detailed exploit chain are not present in the fetched excerpt — likely covered later in the full paper (sections 4+). No CVE ID is given in the available text. The 28-mission figure is explicitly described as inferred from open-source telemetry correlation, not confirmed via direct testing against operational satellites.
Organisations named here
- SatBleed
Technologies named here
- COTS Communication Subsystem modules in small satellites
Techniques named here
- Hostile takeover of satellite Communication Subsystem
Related in Hardware & RF

HAETAE on a Diet: Less Stack, Less Time on Low-End Microcontrollers
geo-tp/ESP32-Bit-Pirate
