Threat model

Independent researchers examining in-orbit satellites and their flight software have found recurring vulnerability classes.

Those findings come from flight software. SpaceOS runs payload software, written in the same languages and shipped through the same update paths, so it inherits the same classes. The mitigations sit at the platform layer rather than in each application.

What the research found

• Willbold and others took an experimental look at satellite software security and found 13 vulnerabilities across three in-orbit satellites, achieving full takeover of two of them (IEEE S&P 2023).
• VisionSpace reported remote code execution, denial of service, and path traversal in a cFS-based flight software distribution (Black Hat USA 2025).
• Curbo and Falco analyzed the spacecraft flight-software attack surface and identified the shared bus as a lateral-movement path (SMC-IT 2024).

Vulnerability classes and the boundary that contains them

Class	Reported by	Where SpaceOS contains it
Memory corruption	Willbold; VisionSpace	The MirageOS path is OCaml, which has no manual allocation. C, C++, and container workloads are not memory-safe, so the partition boundary is what contains them.
Command injection, shell escape	VisionSpace	A unikernel has no shell, no multi-user environment, and no dynamic linker, so there is nothing to escape into.
Weak telecommand authentication	Willbold	Commands are signed objects the node verifies against pinned keys, with sequence numbers and expiry. Possession of a route or an APID grants nothing.
Path traversal	VisionSpace	A unikernel has no filesystem. Storage is a block device with a declared extent.
Privilege escalation inside a workload	Willbold	The workload is already the privilege boundary. A full compromise gains that partition’s authority and nothing else.
Lateral movement across a shared bus	Curbo and Falco	One workload per partition, with no shared kernel between micro-VMs, and a default-deny send_to policy keyed by service identity.
Unverified software update	Willbold	Signed, content-addressed images admitted offline against a pinned root. No committed digest, no launch.
Missing binary hardening	Willbold	Solo5 builds with stack protection, write-xor-execute memory, and seccomp confinement.

A platform boundary limits how far each vulnerability class reaches; it does not remove application bugs.

Check the boundary on a running system

The isolation a workload actually got is in the runtime report, not only in the manifest that asked for it:

space report --json

The report names each service, the isolation backend it received, the interfaces it was granted, and the partition that owns it. A service that asked for a device it was not granted does not start.

Rehearse a release to see the permissions before anything runs:

space deploy payload:release --target sat-42 --plan

The plan prints the resolved space.capability permission list: the exact devices, routes, APIDs, and storage extents the partition may open. Anything absent from that list is unreachable at runtime.

Memory-safety and isolation limits

Memory safety covers the OCaml runtime, the CCSDS stack, and MirageOS services. A C, C++, or Rust workload, and any Linux container, keeps whatever memory-safety properties its own language and toolchain provide; the platform contribution is the isolation boundary around it, not the safety of the code inside.

A container (runc) shares the control-plane kernel, so a kernel escape is a boundary crossing that a micro-VM does not offer. Isolation strength varies by backend, and run.yaml selects the backend explicitly.

Isolation does not confer confidentiality against the operator of the machine. On a standard hypervisor the target operator can read guest memory.