CVE-2026-67969

This vulnerability in NASA cFS Health and Safety (HS) allows a crafted Application Monitor table entry to trigger a processor reset. That sounds like a simple DoS—but in the spacecraft context, a reset isn't a convenience issue; it's a potential mission-kill event, especially during critical operations like burns or communication windows. The CVSS 7.5 score badly understates the real-world stakes because scoring models were built for servers, not flight processors. The root cause is straightforward: HS_MonitorApplications consumes table entries without validating them. The table loading subsystem trusts that validation happened upstream, and upstream assumes the same. This distributed trust model—where every consumer hopes the producer validated—is exactly how these gaps persist. The HS module sits at a critical junction: it detects failures and triggers recovery, with callbacks and watchdog timers wired through it. A crafted table entry doesn't just crash HS—it can interrupt whatever protection HS was actively providing. What you should do: First, verify whether your deployment uses the AppMon table and whether any untrusted source could modify it. If tables originate only from validated ground tools in a trusted operational flow, your exposure is limited to ground segment compromise—but that threat model shift needs explicit acknowledgment. Second, check whether your HS implementation has any bounds checking on table indices or values before acting on them. If it doesn't, that's the gap. Third, examine other table-consuming subsystems in your cFS build—are they making the same trust assumptions? If HS has this flaw, others likely do too. The deeper problem isn't missing validation in one module. It's that cFS has no centralized, enforced validation layer at the table boundary. Different subsystems load different table types with different assumptions about what already happened. That's a systemic architecture issue, not a one-off bug. Any fix should be evaluated against the remediation paradox: adding validation code to a safety-critical recovery subsystem risks introducing new failure modes during the fix deployment. Test any patch in a mission-equivalent environment before uplink.

Reviewed through automated stages and approved by a human before publication.