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.
• 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's how small satellites point their cameras and antennas without burning fuel.

CubeSpace 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 a CRC-32, a simple maths check that spots accidental corruption during a file transfer. It doesn't prove who wrote the file. Anyone with the right cable and the right moment can hand the device a tampered image and it'll run it.

That gap is now tracked as CVE-2026-13743. 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 before launch: on a factory floor, in a cleanroom, or during integration. CISA states clearly the vulnerability isn't exploitable remotely.

The realistic threat model here is supply-chain tampering or an insider with hands-on access, not a remote adversary. CubeSpace's own assessment calls the practical risk low. The bootloader, a separate piece of software that starts the device, operates independently of application firmware and can reload a known-good image, so a tampered wheel is recoverable.

This is the kind of quiet physical-access advisory our 30 June coverage of CISA's Daktronics controller findings also flagged: the headline threat sounds alarming, but the exploitation bar is genuinely high.

What has CubeSpace done about it?

The company released firmware 5.0.20. It 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.

Secure boot is off by default. Customers must 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 flaw carries a CVSS score of 6.1 under version 3.1 and 3.3 under version 4.0, both 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 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, this isn't a Hollywood satellite-hijack scenario. It's a reminder that spacecraft components are built by ordinary companies with ordinary software supply chains. The industry is catching up to security practices that IT learned a decade ago, and this advisory is part of that process. Watch whether operators actually enable secure boot once they upgrade, the default-off design is the real risk here, not the CVE score.