CISA has warned that NASA Core Flight System Health and Safety Application versions 7.0.1 and earlier contain a high-severity flaw that can crash the application and trigger a processor reset. The issue, tracked as CVE-2026-18064, affects a component designed to monitor software health in cFS-based flight and embedded systems.
Published July 30, CISA’s advisory assigns the vulnerability a CVSS 3.1 score of 7.5 and describes it as an incomplete fix for the earlier CVE-2026-15352. Under specific conditions, an attacker able to trigger the affected command can reach a separate NULL pointer dereference, creating a denial-of-service condition.
The Health and Safety application is not a Windows component, and typical Windows PCs are not directly affected. Its importance is in the systems that use NASA’s open-source Core Flight System framework: embedded, mission-oriented deployments where application monitoring and controlled resets are part of normal fault-management operations.
CISA says the vulnerability can cause the HS application to crash, followed by a processor reset. That makes the practical impact availability rather than data exposure or code execution, but availability failures are especially consequential in remote or safety-sensitive systems where a reset can interrupt operations, telemetry, or command processing.
The advisory rates the flaw as network-reachable with low attack complexity and no required privileges or user interaction. Those metrics should not be read as proof that every cFS deployment is exposed to the public internet; they underscore why teams should review command paths, network segmentation, and access controls around any reachable ground or test infrastructure.
For organizations that cannot wait, the interim mitigation is to update from NASA’s HS repository dev branch, beginning with commit
That is a meaningful but operationally awkward distinction: the recommended remediation is a source-level development-branch change, not a packaged production release. Engineering teams should therefore treat it as a controlled software update—review the diff, build it against their specific cFS bundle, run regression and hardware-in-the-loop testing, and confirm compatibility with mission configuration tables before deployment.
Until the official release lands, isolate control and test networks from business networks, keep remote access behind properly maintained VPN and firewall controls, and limit command access to authorized operators. For Windows-based engineering workstations that build, test, or manage cFS environments, the immediate task is less about patching Windows and more about ensuring those systems are not an unsegmented route into affected flight-software infrastructure.
A Health Monitor That Can Be Forced Offline
The Health and Safety application is not a Windows component, and typical Windows PCs are not directly affected. Its importance is in the systems that use NASA’s open-source Core Flight System framework: embedded, mission-oriented deployments where application monitoring and controlled resets are part of normal fault-management operations.CISA says the vulnerability can cause the HS application to crash, followed by a processor reset. That makes the practical impact availability rather than data exposure or code execution, but availability failures are especially consequential in remote or safety-sensitive systems where a reset can interrupt operations, telemetry, or command processing.
The advisory rates the flaw as network-reachable with low attack complexity and no required privileges or user interaction. Those metrics should not be read as proof that every cFS deployment is exposed to the public internet; they underscore why teams should review command paths, network segmentation, and access controls around any reachable ground or test infrastructure.
The Available Fix Is a Development Commit
NASA has not yet released an official fixed HS version. CISA says a supported fix is under development and should arrive in a future software release.For organizations that cannot wait, the interim mitigation is to update from NASA’s HS repository dev branch, beginning with commit
828855f971db4b6714367ed0a970f52dbeab2965. The commit is titled “Add table access protections” and changes code across the HS application, including command handling and monitoring structures.That is a meaningful but operationally awkward distinction: the recommended remediation is a source-level development-branch change, not a packaged production release. Engineering teams should therefore treat it as a controlled software update—review the diff, build it against their specific cFS bundle, run regression and hardware-in-the-loop testing, and confirm compatibility with mission configuration tables before deployment.
Containment Still Matters Before the Release
CISA reports no known public exploitation of CVE-2026-18064 as of July 30. Administrators should nevertheless prioritize an inventory of HS deployments at or below version 7.0.1, especially systems accepting commands across shared networks or remote-access paths.Until the official release lands, isolate control and test networks from business networks, keep remote access behind properly maintained VPN and firewall controls, and limit command access to authorized operators. For Windows-based engineering workstations that build, test, or manage cFS environments, the immediate task is less about patching Windows and more about ensuring those systems are not an unsegmented route into affected flight-software infrastructure.
References
- Primary source: CISA
Published: 2026-07-30T12:00:00+00:00
