PaperlayerView exact revision on arXiv

Source-linked AI summary

SatBleed: Security of Commoditized Communication Modules in Satellites

Ulysse Planta, Julian Rederlechner, Martin Strohmeier, Mathias Fischer, Ali Abbasi

arXiv:2610.06258v1cs.CR

TL;DR

Satellite systems face increasing cyber targeting, and New Space systems are especially vulnerable. The paper develops a COM threat taxonomy and assesses vendor systems, finding at least 28 in-orbit satellites likely vulnerable to persistent takeover.

  • Problem

    Satellite systems are increasingly targeted in cyber attacks and operations, and New Space systems are especially vulnerable.

    Source: §1 · p. 1

  • Method

    The authors develop a threat taxonomy for spaceborne communication subsystems, assess representative systems from common vendors, and use open-source telemetry to estimate real-world impact.

    Source: §1 · pp. 1–2

  • Results

    At least 28 satellites are likely vulnerable to complete, persistent takeover, based on SatNOGS telemetry and vendor disclosures.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings highlight the need to embed security throughout the design lifecycle of COM subsystems.

    Source: §10 · p. 14

    The NewSpace ecosystem is diverse, so the identified vulnerabilities are not necessarily generalizable and do not imply that every system is vulnerable.

    Source: Representativeness of COM Samples · p. 13

Abstract

from arXiv · show

Substantial reduction in launch and manufacturing costs has resulted in the accelerated deployment of small satellite missions, with commercial off-the-shelf (COTS) components becoming the prevailing standard for specific subsystems. However, this modular architecture introduces critical security risks, most notably in the Communication Subsystem (COM), which is continuously exposed by design and implicitly trusted as the entry point for command and control. We construct a tailored threat taxonomy for attacks targeting the COM subsystem and analyze representative COM systems from various vendors. Our findings uncover severe vulnerabilities across firmware, protocols, and architectural designs. This work presents the first in-depth security evaluation of widely deployed COTS COM modules employed in small satellites, identifying vulnerabilities affecting dozens of missions. To assess the real-world impact, we correlate our discoveries with open-source telemetry data, inferring at least 28 vulnerable missions in orbit that are susceptible to hostile takeover. Our work reveals that satellite COM subsystems form an attractive and dangerously neglected attack surface, necessitating urgent attention from the community.

1. Introduction

Small-satellite COM modules are a critical, continuously exposed control interface, yet their security has not received direct evaluation. The paper develops a COM threat taxonomy, assesses representative modules, and uses telemetry to infer at least 28 vulnerable satellites in orbit.

1. Introduction

  • The New Space shift toward modular, COTS satellite building blocks has accelerated small-satellite deployment as launch and manufacturing costs fell.Bespoke designs became economically uncompetitive in a faster innovation environment.Source: §1 · p. 1
  • COM modules remain continuously accessible as the satellite’s only uplink and downlink interface, while in-orbit patching is difficult under data-rate and safety constraints.Their perimeter-guard role is often poorly implemented, potentially facilitating attacks on internal components.Source: §1 · p. 1
  • The authors identify a neglected research gap and conduct an in-depth security evaluation of representative COM modules from widely used vendors, uncovering previously undocumented vulnerabilities.They also introduce a threat taxonomy tailored to TT&C COM subsystems.Source: §1 · pp. 1–2
  • At least 28 satellites are inferred likely vulnerable to complete, persistent takeover, with additional missions exposed to other threats.The estimate combines open-source SatNOGS telemetry and vendor disclosures.Source: §1 · p. 2
  • The paper introduces SyncWordFuzzer, a physical-layer fuzzer designed to trigger bugs in COM sync-word detection.The authors also derive architectural recommendations to improve resilience.Source: §1 · p. 2

2. Background

Small-satellite missions combine reused, interoperable modules with varied ground-to-space communication links and onboard command paths. The background describes these components and interfaces, including how limited isolation and privilege separation can expose the satellite to lateral movement and unrestricted command authority.

2. Background

  • Satellite missions include spacecraft up to 500 kg, and widespread module reuse across small-satellite form factors amplifies the attack surface shared among missions.As of April 2025, 12,149 active satellites were in orbit; CubeSats numbered 2,730.Source: §2 · p. 2

2.1. Satellite Communication

  • Satellite operations use a Mission Control System and ground stations to schedule and uplink telecommands and downlink telemetry, while the COM controls the satellite separately from payload traffic.LEO ground-station passes last minutes and occur several times per day; beacons broadcast status between passes.Source: §2.1 · p. 2, Figure 1 · p. 2

2.2. Small Satellite Subsystems

  • Small satellites are assembled from interoperable, often reused components, and their shared interfaces can leave subsystems without isolation, enabling lateral movement after compromise.PC/104 pin usage is not strictly standardized, and multiple devices may share a bus.Source: §2.2 · pp. 2–3

2.2.1. Subsystem Taxonomy.

  • The COM is the gateway between the satellite platform and the outside world; risky software or configuration updates can sever TT&C and disable fundamental operations.The background also describes OBC, CDHS, ADCS, and EPS roles in satellite computing, command execution, attitude control, and electrical power.Source: §2.2.1 · p. 3
  • OBCs provide satellite computing, while the CDHS processes telecommands; when the COM enforces authentication, unauthenticated attackers cannot reach CDHS components.The CDHS implements operational commands and station-keeping logic.Source: §2.2.1 · p. 3

2.3. Satellite Network Architecture

  • A simple space-protocol frame can carry one command, but onboard networks commonly lack privilege separation, so accepted commands receive equal authority.Commands are disseminated internally to the subsystems that execute them or interpreted directly by the COM.Source: §2.3 · p. 3

3. Criticality of the COM System for Satellites

The section systematizes prior satellite-security research and identifies TT&C communication modules as a largely unevaluated, high-impact space-ground interface. COM systems are exposed gateways to satellite command and internal data, making weaknesses consequential.

3.1. Systematization of Satellite Security Research

  • Prior work spans platform and payload subsystems, ground systems, and links between space and ground, which the authors organize into a research taxonomy.Figure 2 marks the research gap within this systematization.Source: §3.1 · p. 4, Figure 2 · p. 4

3.1.1. Space.

  • Studies of satellite data buses report DoS and spoofing risks, while platform and payload research identifies firmware-update, isolation, implementation, and parsing flaws.The cited work covers buses including CAN and MIL-STD-1553B,, platform components,,, and payload interfaces.Source: §3.1.1 · p. 4

3.1.2. Ground.

  • Ground-system studies report access-control, scheduling, and logging weaknesses, while user-service protocols have shown DoS and confidentiality flaws.Link-layer TM/TC protocols have also been analyzed for replay, spoofing, and framing weaknesses,.Source: §3.1.2 · p. 4

3.1.3. Space-Ground Interfaces.

  • Research on payload RF links and transponders reports link-layer attack susceptibility, and VSAT assessments find hardware and firmware flaws; TT&C transceivers and ground-station RF hardware lack security evaluations.The cited studies include,,, and.Source: §3.1.3 · p. 4

3.2. Research Gap: COM Systems and TT&C Links

  • The authors identify a research gap in COM components used for TT&C, both space-based and ground-based, despite their high-impact attack surface.They suggest that the sensitivity of these components on larger customized satellites may make information about them difficult to obtain.Source: §3.2 · p. 4, Figure 2 · p. 4

3.3. Importance of the Communication System

  • COM is the sole command-uplink and telemetry-downlink link, directly exposed over RF and connected to internal buses; omnidirectional links can enable drive-by exploitation and a DoS flaw may make a satellite uncontrollable.COM complexity ranges from raw-frame transceivers to systems that parse packets, fragment data, route, or store and forward telemetry.Source: §3.3 · pp. 4–5
  • Matching ground-station hardware can share vulnerabilities with spacecraft COMs, and very low-power attacks may evade monitoring; safety priorities also leave proprietary link-protection protocols little evaluated.Diagnostic backdoors and clear modes are included to support mission continuity,.Source: §3.3 · p. 5
  • Compromised COM software is difficult to reset, none of the analyzed COMs has a resilient fallback, and the paper examines hardware, protocols, firmware, and operational practices.The authors note that lateral movement can preserve access without further measures.Source: §3.3 · p. 5

4. COM Subsystem Threats

The section describes large-scale threat scenarios and derives a COM-focused taxonomy for analyzing the weaknesses that could enable them. It also sets out attacker capabilities and practical constraints relevant to those threats.

4.1.1. Space Botnets.

  • A COM monoculture could let one vulnerability compromise many satellites, enabling self-propagating attacks or compromised COMs to form RF-jamming networks that disrupt links.Satellite-to-satellite communications may exacerbate propagation, while COMs generally do not tolerate another transmitter on the same channel,.Source: §4.1.1 · p. 5

4.1.2. Satellite Spyware.

  • An attacker could move from a compromised COM or OBC to a powered-off redundant unit, simulate primary failure, and maintain persistent access without operator awareness.From the backup, spyware may collect payload data, falsify commands, and exfiltrate information through covert channels in normal downlink frames.Source: §4.1.2 · p. 5

4.2. COM Subsystem Sub-Components

  • The authors derive a sub-component threat model from six COMs, modeling hardware, software, information flow, and trust boundaries to locate weaknesses and visualize exploit chains.The model highlights numerous entry points for unauthenticated, potentially malicious inputs.Source: §4.2 · pp. 5–6, Figure 3 · p. 6

4.3. Attacker Model

  • The attacker model distinguishes short-duration physical access, TT&C-link interception, malicious transmission, ground-station attacks, and low-privileged insiders.A TT&C-link adversary need not be able to prevent message delivery.Source: §4.3 · p. 6

4.3.1. Modeling Restrictions.

  • The analysis abstracts practical hurdles including short LEO contact windows, directional-antenna and Doppler requirements, transmit power, and the risk of geolocation from persistent transmissions.LEO passes may last only minutes and occur a few times per day, depending on orbit and attacker location.Source: §4.3.1 · p. 6

4.4. Generalized COM Threat Taxonomy

  • The generalized taxonomy maps hypothesized threats to COM sub-components and the weakest attacker type required, assuming the idealized architecture's data flows.Non-ideal real-world implementations may allow exploitation by weaker attackers than the taxonomy indicates.Source: §4.4 · p. 7

5. Evaluation of COTS COMs

The evaluation applies a COM-specific threat taxonomy to three vendor systems and identifies weaknesses spanning protocols, firmware, and architecture. Its findings include SATBLEED and vulnerabilities that can enable persistent denial of service or code execution.

5. Evaluation of COTS COMs

  • The evaluation uses a taxonomy-guided review of three real-world COMs, selected using criteria aimed at operational impact and market relevance.The taxonomy guided systematic checks of data flows and threat vectors; the evaluation excludes issues caused by fundamentally insecure configurations.Source: §5 · p. 7, §5.1 · p. 7

5.3.2. Replay TTCLA .

  • On the NanoCom AX100, replayed internal-service messages can alter settings and cause persistent denial of service, even with HMAC verification enabled.The authors also explain that a single authenticated telecommand payload could be used to disable later authentication enforcement, and that secure rekeying requires the CDHS to relay the key.Source: §5.3.2 · p. 9, §5.3.3 · p. 9

5.3.4. Command Injection MI .

  • The AX100’s debug shell can be reached through command injection and supports access to arbitrary packets, parameters, and memory, creating routes to persistent access or code execution.A connected CSP node can reflect a payload into the shell; a separate CMP service exposes a function pointer used for memory access.Source: §5.3.4 · p. 9, §5.3.5 · p. 9, §5.3.8 · p. 10

5.3.6. Timing and RF Leakage Based Side-Channels

  • AX100 analysis finds non-constant-time HMAC comparison and computation-dependent RF leakage, while its 32-bit HMAC tag may be brute-forced online on high-rate links.The authors estimate that at 50 Mbit/s, forging the tag could take under 10 hours.Source: §5.3.6 · pp. 9–10, §5.3.7 · p. 10

5.3.9. Syncword-Based DoS

  • SyncWordFuzzer exposed a likely timing-dependent race that can make the AX100 accept random RF input as frames, degrading reception without a transmitter.The behavior is not reliably triggered by timing-accurate replays and appears to depend on internal timing conditions combined with input sequences.Source: §5.3.9 · p. 10

5.3.10. Logic Error in TM Handling (SATBLEED) TTCLA .

  • SATBLEED lets an attacker inject a key request into a ground station over RF, which responds even when the request is nonsensical.The vulnerability can persist even when telemetry encryption is present, because the COM processes telemetry before higher-layer cryptographic handling.Source: §5.3.10 · p. 11
  • The AX100 also stops transmitting when it detects RSSI above its default -95 dBm threshold, making jamming effective with a low-power signal.Source: §5.3.10 · p. 11

5.4. Libre Space Foundation SatNOGS-COMMS

  • SatNOGS-COMMS uses a 4-byte authentication tag and a fixed secret that can authenticate arbitrary telecommands after one interception, while Endurosat’s unsigned updates permit malicious firmware installation.Endurosat’s unauthenticated debug and bootloader interfaces also allow firmware manipulation, with no capability to restore a known-good state afterward.Source: §5.4.1 · p. 11, §5.4.2 · p. 11, §5.5.2 · p. 11

6. Feasibility and Impact of SATBLEED

The authors use passive SatNOGS beacon observations to estimate the active missions plausibly affected by SATBLEED. Under their stated assumptions, 28 of 64 missions are plausibly vulnerable, but the estimate is a lower bound rather than an active validation.

6. Feasibility and Impact of SATBLEED

  • The estimate uses SatNOGS recordings from 80 transmitters across 64 active missions, attributed to NanoCom AX100 use because Mode 5 is its only known implementation.The analysis assumes firmware equivalent to versions available in April 2025, no mission-specific variants, and vendor-provided ground infrastructure plausibly based on the GS100.Source: §6 · p. 12
  • 28 of 64 active missions in the dataset are plausibly vulnerable to SATBLEED under the authors’ assumptions.Twelve transmit beacons without GS100-enforceable HMAC protection, and 16 frequently toggle this configuration.Source: §6 · p. 12
  • Because the analysis relies on passive observation rather than active validation and covers only missions observed by SatNOGS, its estimate is a lower bound.Encrypted or compressed beacons complicate classification, and beacon observations do not reveal all encryption or authentication settings.Source: §6 · p. 12

7. Contextual Factors Behind Security Gaps

Testing satellite COMs is difficult because integrated hardware and software, timing-sensitive peripherals, and low-level radio protocols constrain emulation and automated testing. Across the evaluated systems, the authors also identify weak separation of management commands from user data, missing secure boot, and non-defensive cryptographic code practices.

7. Contextual Factors Behind Security Gaps

  • Integrated radios, timing-critical hardware interactions, and low-level symbol processing make accurate emulation difficult and push much COM security testing toward costly, time-consuming flight-representative hardware.Public instruction-set emulators may also be incomplete for the exotic processor architectures used by some radio subsystems.Source: Testing Challenges · p. 12
  • Across all evaluated systems, user data and management commands lack explicit separation, and injected radio traffic can issue COM commands outside the nominal CDHS path.Source: No Separation of Data and Commands… · p. 12
  • Two of the three evaluated COMs lack secure boot, while the AX100 and SatNOGS-COMMS use non-constant-time comparisons and SatNOGS-COMMS also discards cryptographic error values.The paper notes that defensive error checking matters in space because particle-induced faults can leave programs in an invalid state.Source: Missing Secure Boot Features · p. 12, Non-Defensive Use of Cryptographic… · p. 12

8. Security Hardening Measures

The hardening measures call for less implicit trust between satellite components, stronger isolation and recovery mechanisms, and security controls adapted to space-system constraints.

8. Security Hardening Measures

  • Verify signatures on the device executing a command and authenticate internal commands to distinguish transported data from commands sent directly to the COM.Authenticated, time-limited thruster commands are given as an example of preventing malware on another component from masquerading as the CDHS.Source: §8 · p. 12, Introduction of Privilege Separation · pp. 12–13
  • A wavelength-isolated optical bus could retain a shared medium while isolating nodes and providing galvanic isolation.The proposed alternative addresses PC/104's shared digital interfaces, whose security improvements may be adopted slowly and require evaluation in conditions they were not designed for.Source: Moving Away From PC/104 · p. 13
  • Satellite recovery needs a supervisory system that can restore state from a trusted position, because fallback software cannot be assumed trustworthy.The supervisor must avoid increasing failure risk and be able to override core functionality.Source: Recovery Methods for On-board Software · p. 13
  • Rapid patching and defense-in-depth could address software monoculture, but patches need safe deployment mechanisms and vendors should weigh basic mitigations such as stack canaries.The authors note that patches are rarely deployed on space hardware due to safety concerns.Source: Adapting Best Practices from Other… · p. 13
  • Watchdog timers can let operators choose whether to passivate or continue with accepted risk when an attack or failure disables a security function.This addresses concerns that security mechanisms may raise power use, complexity, or failure risk in a mission where failure is costly.Source: Restrictions Posed by the Space… · p. 13
  • Security features should support phased rollout and have carefully hardened backups or alternative ways to achieve the same goal.The proposed approach allows protection to be deployed to part of a system before extending it to all components.Source: Restrictions Posed by the Space… · p. 13
  • Proposed mitigations must be evaluated for radiation-induced single-event upsets and possible component-lifetime impacts from added processing or resource use.Source: Restrictions Posed by the Space… · p. 13

9. Discussion

The discussion indicates that vulnerabilities may affect more COMs and missions than the specific analyzed samples suggest, while explaining boundaries in impact estimation and vulnerability generalization.

9. Discussion

  • Vendors confirmed that other COMs in their portfolios share some vulnerabilities, so the impacted mission total probably exceeds estimates based on specific hardware.Source: §9 · p. 13

9.1. Limitations

  • The telemetry survey excludes encrypted or compressed missions because their payloads obscure HMAC detection, making the reported SATBLEED impact a strict lower bound.Encryption and compression do not mitigate SATBLEED; they obscure the presence of integrity protection.Source: Open Source Telemetry Survey · p. 13
  • The analyzed providers have significant market share, but diverse architectures limit generalizing concrete vulnerabilities, some of which arise from provider-specific choices.The findings indicate common security oversights, not that every system is likely vulnerable.Source: Representativeness of COM Samples · p. 13
  • Manual reverse engineering, hardware inspection, and targeted fuzzing do not prove the analyzed devices lack further flaws.Given firmware opacity, the authors consider additional vulnerabilities in the analyzed COMs likely.Source: Completeness of Methodology · pp. 13–14

10. Conclusion

The paper develops a COM threat model, evaluates communications subsystems from three major vendors, and reports vulnerabilities with evidence of vulnerable active satellites.

10. Conclusion

  • The evaluation uncovers critical vulnerabilities and, using open-source SatNOGS telemetry, identifies 28 vulnerable in-orbit active satellites.Broader testing also finds weaknesses including insufficient replay defenses and insecure update mechanisms.Source: §10 · p. 14

11. Ethics considerations

The authors describe responsible disclosure and controlled testing, while limiting the release of details that could enable immediate weaponization. The appendix outlines how SatNOGS telemetry was processed to estimate HMAC use, with uncertainty in some classifications.

11. Ethics considerations

  • The authors disclosed identified vulnerabilities to vendors; GomSpace and Endurosat acknowledged them and plan fixes for next-generation modules.GomSpace also said fixes are planned for some currently available models.Source: Responsible Disclosure · p. 14
  • The paper withholds vulnerable mission identities and working exploits or payload generators to reduce targeting and immediate weaponization risks.The authors publish summarized results and statistical analysis instead of naming the 28 missions.Source: Non-Attribution of Vulnerable Missions · p. 14
  • Experiments used isolated setups or vendor hardware in controlled environments, avoided RF transmission and leakage, and did not interact with operational satellite links.The authors acknowledge that publication may still be replicated or inferred by motivated, technically capable attackers, while judging disclosure benefits to outweigh the risks.Source: Avoiding Harm During Analysis · p. 14, Ethical Limitations · p. 14

Appendix A. SatNOGS Survey Details

  • The SatNOGS survey downloads up to 10,000 demodulated samples per mission, decodes them using CSPv2, and examines HMAC data because flags may be misused.Duplicate, incomplete, and encrypted samples are filtered before estimating entropy through Hamming distances between samples.Source: Appendix A · p. 16
  • The survey labels missions with fewer than 20 usable samples as insufficient and uses flag counts and Hamming-distance thresholds to classify HMAC use.Fewer than five HMAC-flagged samples and average Hamming distance below 14 are used to tag a mission as not using HMACs.Source: Appendix A · p. 17
  • When HMAC flag counts conflict with observed entropy, the survey cannot confidently determine true HMAC usage.The described cases include underused and overused HMAC flags, which may reflect incorrect flag use or variable payload data.Source: Appendix A · p. 17

Appendix B. Additional Data/Attack Flows

The appendices show sub-component views of COM data and attack flows, then measure AX100 RF spectra under different MCU workloads. The meta-review summary describes an empirical analysis of COTS satellite communication modules and their vulnerabilities.

Appendix B. Additional Data/Attack Flows

  • Figure 6 presents a sub-component-based view of data and attack flow for the GomSpace NanoCom AX100, with labels identifying processing, routing, interfaces, data types, and vulnerability classes.Shown labels include Baseband Processing, RF-Frontend, Internal Commands, Frame Processing, Debug / Config, Routing, Network Interfaces, Unauthenticated Data, Authenticated Data, Internal Configuration, Denial of Service, Arb. Code Exec., and Other Vuln.Source: Figure 6 · p. 17, Appendix B · p. 17
  • Figure 7 notes that an open MCU debug interface depends on mission-owner choice and is not a flaw of the COM product.Source: Figure 7 · p. 18

Appendix C. RF-Measurements of AX100

  • Figure 8 measures the transceiver's RF spectrum while the MCU executes different workloads.Source: Figure 8 · p. 18

Appendix D. Meta-Review

  • Appendix D identifies the following text as a program-committee meta-review prepared for the 2026 IEEE Symposium on Security and Privacy review process.Source: Appendix D · p. 18

D.1. Summary

  • The paper analyzes COTS satellite communication modules from several vendors using reverse engineering and testing, identifying vulnerabilities in firmware and system design.It discusses potential implications for deployed satellite missions.Source: §D.1 · p. 18

D.2. Scientific Contributions

The scientific-contributions section characterizes the paper as an empirical security analysis of widely used satellite COM modules. It presents the work as identifying vulnerabilities in real implementations and as relevant to multiple deployments.

D.2. Scientific Contributions

  • The contribution headings characterize the work as identifying an impactful vulnerability, advancing an established field, and establishing a new research direction.Source: §D.2 · p. 18

D.3. Reasons for Acceptance

  • The paper presents an empirical security analysis of widely used COTS satellite communication modules and identifies vulnerabilities in real implementations.Source: §D.3 · p. 18
  • The work highlights COM modules as an important security boundary and weaknesses in reused components that may affect multiple deployments.Source: §D.3 · p. 18
Loading 2610.06258v1…