Satellite reaction wheel flaw lets attackers with physical access swap in malicious firmware

Key points

• CISA published an advisory on 2 July 2026 warning that CubeSpace's CW0057 Reaction Wheel, a small spacecraft part used to steer satellites, does not properly check who signed its firmware before installing it.
• The flaw is tracked as CVE-2026-13743 and affects every firmware version before 5.0.20.
• An attacker needs physical access to the hardware to exploit it; it cannot be done over the internet.
• CubeSpace, headquartered in South Africa, has shipped firmware 5.0.20 with an optional secure boot feature that customers must switch on themselves.
• The researcher Anthony Rose reported the issue to CISA, which says no public exploitation has been observed.

A reaction wheel is a spinning metal disc inside a satellite. Speed it up or slow it down and the spacecraft turns. It is how small satellites point their cameras and antennas without burning fuel.

CubeSpace, a South African company, sells one of the popular models — the CW0057. According to a CISA advisory published on 2 July 2026, the device has a weakness in how it accepts new firmware, meaning the low-level software that runs the hardware.

The wheel checks incoming firmware with something called a CRC-32. That is a simple maths check that spots accidental corruption during a file transfer. It does not prove who wrote the file. Anyone with the right cable and the right moment can hand the device a tampered image and it will run it.

That gap is now tracked as CVE-2026-13743, a formal industry identifier for the flaw. In plain terms: the wheel trusts firmware without confirming the source.

Can someone hack a satellite from their laptop?

No. The attacker needs to physically touch the device, which in practice means access to the wheel before it launches — on a factory floor, in a cleanroom, at a supplier, or during integration with the rest of the satellite. CISA states clearly the vulnerability is not exploitable remotely.

That matters for how you read this story. The realistic threat model here is supply-chain tampering or an insider with hands-on access, not a hacker in another country pushing a button.

CubeSpace's own assessment, published alongside the advisory, calls the practical risk low. The company notes the bootloader — a separate piece of software that starts the device — is independent of the application firmware and can reload a known-good CubeSpace image. So a tampered wheel is recoverable, not permanently broken.

What has CubeSpace done about it?

The company released firmware version 5.0.20. That version adds cryptographic secure boot, a mechanism where the device checks a digital signature before running any firmware. Think of it like a wax seal on a letter: if the seal is wrong, the device refuses to open the envelope.

There is a catch. Secure boot is off by default. Customers have to switch it on, and CubeSpace recommends the fully immutable mode for the strongest protection. Operators who upgrade the firmware but skip that step are still exposed.

The vulnerability was reported to CISA by researcher Anthony Rose. It carries a CVSS score of 6.1 under version 3.1 and a lower 3.3 under version 4.0, reflecting the physical-access requirement.

What should satellite operators do now?

Upgrade to 5.0.20 and turn signed boot on. Confirm every wheel in inventory, in integration, or already flying under your control is running the new firmware. Tighten who can physically touch flight hardware during assembly and transport, and keep an audit trail.

For everyone else — the mainstream reader watching space news — this is not a Hollywood satellite-hijack scenario. It is a quiet reminder that spacecraft components are built by ordinary companies with ordinary software supply chains. The industry is slowly catching up to security practices that IT learned a decade ago. This advisory is part of that catching up.