Jherrod ThomasThe Lion of Functional Safety™

July 6, 2026 · 14 min read

NIST SP 800-193 / CWE-347SPARTA / NIST IR 8270CCSDS / ISO 24113

When the Reaction Wheel Would Boot Anything: The CubeSpace CW0057 Secure-Boot Gap Through a NIST SP 800-193 and SPARTA Lens

A reaction wheel is not a payload. It is not the flight computer, not the radio, not the camera anybody buys the satellite for. It is a 115-gram spinning mass that keeps the spacecraft pointed. And that is exactly why the July 2 advisory is worth your time: the component nobody thinks of as a computer turned out to run firmware it would accept from anyone, and the integrity check it did run was checking the wrong thing.

On July 2, 2026, CISA published advisory ICSA-26-183-02 for the CubeSpace CW0057 reaction wheel, covering CVE-2026-13743, an Improper Verification of Cryptographic Signature flaw (CWE-347) reported by researcher Anthony Rose. The short version: firmware versions prior to 5.0.20 authenticate a firmware update with a CRC-32 check. CRC-32 tells you the image arrived without bit-errors. It tells you nothing about who produced it. An attacker who can reach the device can load arbitrary firmware onto the wheel, and the wheel will run it.

I want to walk this one carefully, because the reflexive reactions to it are both wrong. The first wrong reaction is "CVSS 6.1, physical access only, move on." The second is "satellite hacking, we're all doomed." Neither is the engineering story. The engineering story is a missing root of trust on a motion-control actuator, and a component vendor whose threat model stopped at "did the file transfer cleanly."

The public record

CubeSpace, based in Stellenbosch, South Africa, makes attitude-determination-and-control hardware for CubeSats and small satellites. The CW0057 is a Gen-2 CubeWheel: 115 g, 35 by 35 by 24.2 mm, roughly 5.7 mNms of stored angular momentum at 6000 RPM, 10,000 RPM maximum, with integrated drive electronics (SatCatalog component sheet; CubeSpace product page). It is a commodity actuator that flies in constellations worldwide, which is the part that matters.

CISA's advisory is specific about the mechanism. Per the vendor's own remediation notes quoted in the advisory, "the CW0057 reaction wheel authenticates firmware updates with a CRC-32 integrity check, which confirms image integrity but does not verify the source of an image" (CISA ICSA-26-183-02; ASSURANT mirror of the advisory). Firmware prior to 5.0.20 is affected. Version 5.0.20 "introduces the capability for cryptographically verified secure boot; however, this protection is not enabled by default. Users must activate signed-boot functionality, particularly the fully immutable mode, to achieve full security" (ISSSource).

The scoring is split, and the split is the interesting part. CVSS 3.1 comes out at 6.1 (Medium) on vector AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H — physical access, no privileges, high integrity and availability impact. CVSS 4.0 drops it to 3.3 (Low), largely because 4.0 penalizes the physical-access prerequisite more heavily (CISA advisory metrics). CubeSpace assesses practical risk as low, noting that exploitation needs direct physical access and that the bootloader is independent of the application firmware, so a bricked-looking unit can be reflashed with a known-good CubeSpace image and is not permanently disabled.

That last point is true and it is also where the vendor's threat model and mine part ways. "Recoverable" assumes you know the wheel was tampered with. The whole value of a firmware implant is that it does not announce itself. Which brings us to why "physical access only" is doing less work than it looks like.

The standards lens

There is no ISO 26262 for spacecraft. People reach for that reflex and it does not fit. The right lenses here are three, and none of them are automotive.

NIST SP 800-193, Platform Firmware Resiliency Guidelines. This is the cleanest fit and I will lean on it hardest. SP 800-193 organizes firmware security into three properties: Protection, Detection, and Recovery. Protection means the platform only executes authentic firmware — an update must be verified against an authorized signing authority before it runs. Detection means the platform can tell when its firmware has been corrupted. Recovery means it can restore a known-good image. Read the CW0057 against that trio and the failure is precise: the CRC-32 gives you a weak form of Detection (it catches accidental corruption) and the independent bootloader gives you Recovery. What is completely absent, pre-5.0.20, is Protection. The device has two of the three legs and the missing leg is the load-bearing one. A CRC is not a cryptographic authentication mechanism; SP 800-193 explicitly requires that update images be authenticated using an approved digital signature scheme rooted in a hardware or immutable root of trust.

CWE-347, Improper Verification of Cryptographic Signature — which is generous, because there is no signature to improperly verify; there is a checksum standing in for one. CWE-347 is the CISA-assigned weakness and it is the correct family: the system fails to establish that data came from a trusted source before acting on it. In firmware terms, CRC-32 is not merely weak, it is not a signature at all. It has no secret and no asymmetric key, so anyone who can compute a CRC — which is everyone — can produce an image the device will accept.

SPARTA and NIST IR 8270 for the space-specific threat framing. The Aerospace Corporation's SPARTA matrix (Space Attack Research and Tactic Analysis) is the space-segment analogue to MITRE ATT&CK, and it names this exact move: gaining persistence on a spacecraft component and using a trusted auxiliary device as a foothold. NIST IR 8270, Introduction to Cybersecurity for Commercial Satellite Operations, frames the same concern at the mission level — the ground-to-space supply chain and pre-launch integration window are attack surfaces, not just the RF link. This reframes "physical access only" from a mitigating factor into a description of the most likely attack path. Nobody is going to fly to orbit and plug into a reaction wheel. They are going to reach it during integration, test, storage, or transport — the pre-launch window where dozens of hands touch a bus and a COTS actuator sits waiting for firmware. The recent academic work on this — the SpyChain study of multi-vector supply-chain attacks on small satellites using NASA's NOS3 simulator — makes the point that auxiliary COTS components "often lack robust assurance yet enjoy comparable access to critical on-board resources" (SpyChain, arXiv:2510.06535). A reaction wheel is precisely such a component.

Now the consequence side, because integrity and availability of an attitude actuator are not abstract. A reaction wheel is the thing that points the spacecraft. Corrupt or command it maliciously and you can bleed the pointing budget that keeps solar panels sunward (power loss), keeps the radiator away from the sun (thermal), and keeps the antenna on the ground station (comms). Push it further and you have an uncommanded slew or a saturating momentum state. In a crowded orbit, loss of attitude control is not only a mission-availability problem, it is a space-safety problem — which is where ISO 24113 (space debris mitigation) and the operator's collision-avoidance obligations enter the picture. An actuator whose firmware anyone can replace is, in the worst framing, a remotely-implantable way to turn a healthy satellite into an uncontrolled object.

A worked snippet — firmware-resiliency FMEA (NIST SP 800-193 properties as controls)

I score this as a security-informed FMEA with Severity / Occurrence / Detection and an AIAG-VDA-style Action Priority, because "CVSS 6.1" collapses too much into one number. Severity here is mission/space-safety severity, not injury.

| Function (SP 800-193 property) | Failure mode | Effect | S | O | D | AP | Control | |---|---|---|---|---|---|---|---| | Protect: run only authentic firmware | No source authentication; CRC-32 accepted in place of a signature | Attacker loads arbitrary firmware into the ACS actuator | 9 | 5 | 8 | High | Enforce signed boot rooted in an immutable RoT; reject any image whose signature does not chain to a provisioned key | | Detect: know when firmware is not authentic | CRC-32 detects bit-errors only; a valid-CRC malicious image is indistinguishable from genuine | Implant runs silently; "recoverable" never triggers because tampering is invisible | 8 | 5 | 9 | High | Measured boot with attestation of the running image hash to the OBC; log measurement mismatch | | Recover: restore known-good image | Bootloader can reflash CubeSpace image — but only if operator knows to | Recovery depends on detection that does not exist | 6 | 4 | 7 | Medium | Tie recovery to a failed attestation, not to a human noticing anomalous behavior | | Integration-window control | Pre-launch handling of COTS actuator not access-controlled | Supply-chain implant during test/storage/transport | 9 | 4 | 7 | High | Chain-of-custody + firmware attestation at integration acceptance gate |

The row that should stop a reviewer is the Detect row: Detection rating 9. A malicious image with a correct CRC is, to this device, identical to a genuine one. You cannot recover from a compromise you cannot see, which is why the vendor's "the unit is recoverable" comfort is thinner than it sounds.

A worked snippet — attack path (top event: persistent attitude-control implant)

Top: Malicious firmware persists on CW0057 in flight
        AND
        ├── 1. Attacker reaches the update interface
        │       OR
        │       ├── 1a. Pre-launch access during integration / test / storage
        │       ├── 1b. Transport or third-party handling of the COTS unit
        │       └── 1c. Insider at any tier that touches the bus
        └── 2. Device accepts the unauthorized image
                AND
                ├── 2a. No cryptographic source verification (CRC-32 only)   [CWE-347]
                ├── 2b. Secure boot absent (pre-5.0.20) OR not enabled (5.0.20 default)
                └── 2c. No boot-time attestation to the OBC to flag the swap

Note the structure. Branch 2 is a two-of-two AND: even after 5.0.20 ships, the vulnerability effectively persists unless the operator turns on signed boot, because the fix is off by default. A safety-relevant control that ships disabled is a control that most fleets will fly without. That is not a hypothetical — it is the predictable result of shipping "capability" instead of "default."

Derived requirements (excerpt)

Stable IDs, testable thresholds, mapped to the standard that motivates them.

What the headline really tells us

The headline is "reaction wheel firmware flaw, medium severity, physical access." Read it as an artifact that was never written: a firmware-resiliency requirement on a motion-control component. The vendor built a device that checks whether a firmware image arrived intact and called that authentication. It is not. Integrity without authenticity is a spell-checker without a signature block — it confirms the letter is well-formed while saying nothing about who wrote it.

The deeper lesson is about where the assurance boundary sits. Flight software gets scrutiny; the framework it runs on (cFS and its kin) is developed under chain-of-custody discipline. The reaction wheel, the star tracker, the magnetorquer — the auxiliary COTS parts — inherit the same bus access and almost none of the same rigor. That asymmetry is the vulnerability. CVE-2026-13743 is not really about CRC-32 versus ECDSA. It is about a component class that everyone trusts and no one attests. The fix that shipped is real, and it ships turned off, which means the actual remediation is a fleet-wide configuration campaign plus an integration-gate check that most small-sat programs do not yet run. Put the secure-boot requirement in the actuator spec, put the attestation in the acceptance gate, and turn the control on by default. None of that is invention. It is the discipline of writing the row down.

— Jherrod Thomas, The Lion of Functional Safety™

Sources