CISA has issued an industrial-control advisory for CVE-2026-15352, a high-severity denial-of-service flaw in NASA’s Core Flight System Health & Safety application. The vulnerable component can crash with a segmentation fault while processing a routine Housekeeping Telemetry request, potentially taking the application offline. NASA recommends updating to cFS Health & Safety version 7.0.1.
The July 16 advisory rates the issue 7.5 under CVSS v3.1 and 8.2 under CVSS v4.0. CISA’s scoring reflects a remotely reachable condition that needs no authentication or user interaction, with availability as the primary impact. There is no indication that the defect enables code execution, data theft, or configuration changes—but in systems where the Health & Safety application is part of an operational flight-software stack, a predictable crash is still a serious reliability problem.
According to CISA, no public exploitation targeting this vulnerability had been reported at publication. The advisory credits Grady DeRosa with reporting the issue.
The bug is categorized as CWE-476, a NULL pointer dereference. In practical terms, the Health & Safety application can attempt to use an object or memory reference that has not been correctly initialized or is otherwise invalid. The result is a segmentation fault rather than graceful request rejection or fault handling.
What makes CVE-2026-15352 notable is the affected operation: Housekeeping Telemetry. In cFS environments, housekeeping data is routine operational information used to report software and platform status. Requests for it are not inherently suspicious; that is precisely why an input-handling flaw in this path deserves attention.
CISA describes the outcome as a denial of service. That means the immediate concern is interruption of the HS application, not necessarily loss of an entire spacecraft, ground segment, or mission-control environment. Still, Health & Safety is not an incidental add-on. NASA’s own software catalog describes HS as a core cFS plug-in providing application monitoring, event monitoring, watchdog servicing, optional execution-counter reporting, and CPU-aliveness indications.
A crash in the component responsible for observing whether other components remain healthy creates an uncomfortable operational gap. The system may have separate watchdogs, supervisors, redundancy, restart policies, and ground procedures, but administrators should not assume those safeguards eliminate the impact without testing their own deployment.
For Windows administrators, this is not a Windows 11 or Windows Server vulnerability. NASA’s software catalog lists the Health & Safety application as Linux software, and its typical home is embedded or mission-oriented cFS deployments rather than endpoint fleets. The Windows relevance is more likely to be indirect:
That timing matters. Organizations may already have the corrected version available in their source-management workflow without having incorporated it into their mission-specific builds. In aerospace and industrial environments, however, “update available” is not the same as “update deployed.” A patch can require compatibility testing against the Core Flight Executive, operating-system abstraction layer, platform support package, mission apps, message definitions, and existing telemetry expectations.
The practical response should begin with an inventory rather than an indiscriminate upgrade. Teams should identify HS source trees, built artifacts, simulator images, hardware-in-the-loop labs, and any inherited cFS bundles that include a pre-7.0.1 release. They should also determine whether Housekeeping Telemetry commands are reachable from networks beyond a tightly controlled operations segment.
For deployments that cannot be immediately rebuilt or requalified, the compensating controls are familiar but important:
Exposure depends on each implementation’s command routing, network architecture, radio or ground-link design, authentication layers, and operational procedures. A lab simulator on a shared engineering network carries a different risk profile from an isolated flight-software target reachable only through controlled ground infrastructure.
That nuance should shape remediation priorities. Internet-facing or broadly routed test systems deserve immediate attention, especially if they accept telemetry-related traffic from networks that include unmanaged developer machines, contractors, or shared services. More isolated systems still need the update, but their scheduling can be governed by mission assurance, regression testing, and maintenance windows.
The absence of known public exploitation should likewise be read as a status report, not a reason to defer action. Public proof-of-concept code is not required for a simple availability flaw to become operationally disruptive.
For teams operating NASA cFS Health & Safety builds older than 7.0.1, the priority is to locate the deployed version, test the updated software against mission-specific integrations, and close unnecessary access to telemetry interfaces in the meantime. The next meaningful milestone is not the advisory itself—it is whether version 7.0.1 has made it into the actual images and systems that operators rely on.
The July 16 advisory rates the issue 7.5 under CVSS v3.1 and 8.2 under CVSS v4.0. CISA’s scoring reflects a remotely reachable condition that needs no authentication or user interaction, with availability as the primary impact. There is no indication that the defect enables code execution, data theft, or configuration changes—but in systems where the Health & Safety application is part of an operational flight-software stack, a predictable crash is still a serious reliability problem.
According to CISA, no public exploitation targeting this vulnerability had been reported at publication. The advisory credits Grady DeRosa with reporting the issue.
A Telemetry Request Can Take the Service Down
The bug is categorized as CWE-476, a NULL pointer dereference. In practical terms, the Health & Safety application can attempt to use an object or memory reference that has not been correctly initialized or is otherwise invalid. The result is a segmentation fault rather than graceful request rejection or fault handling.What makes CVE-2026-15352 notable is the affected operation: Housekeeping Telemetry. In cFS environments, housekeeping data is routine operational information used to report software and platform status. Requests for it are not inherently suspicious; that is precisely why an input-handling flaw in this path deserves attention.
CISA describes the outcome as a denial of service. That means the immediate concern is interruption of the HS application, not necessarily loss of an entire spacecraft, ground segment, or mission-control environment. Still, Health & Safety is not an incidental add-on. NASA’s own software catalog describes HS as a core cFS plug-in providing application monitoring, event monitoring, watchdog servicing, optional execution-counter reporting, and CPU-aliveness indications.
A crash in the component responsible for observing whether other components remain healthy creates an uncomfortable operational gap. The system may have separate watchdogs, supervisors, redundancy, restart policies, and ground procedures, but administrators should not assume those safeguards eliminate the impact without testing their own deployment.
cFS Is Open Source, but Deployments Are Far From Uniform
NASA’s Core Flight System is an open-source, reusable flight-software framework. The project’s public documentation identifies HS as one of the cFS applications, and NASA has described cFS use across spacecraft, small satellites, ground-adjacent development environments, and autonomous systems. That broad reuse is helpful for engineering teams, but it also means the affected code may appear in builds that do not neatly identify themselves as “NASA software.”For Windows administrators, this is not a Windows 11 or Windows Server vulnerability. NASA’s software catalog lists the Health & Safety application as Linux software, and its typical home is embedded or mission-oriented cFS deployments rather than endpoint fleets. The Windows relevance is more likely to be indirect:
- Windows-based engineering workstations may build, test, monitor, or package cFS software through WSL, virtual machines, containers, or cross-compilation toolchains.
- Windows-hosted CI/CD runners may pull an affected HS source version into test images or firmware builds.
- Operations teams may use Windows systems to access telemetry consoles, lab networks, or ground-support infrastructure connected to cFS targets.
- Asset inventories may overlook the issue because the deployed binary is an internally built image rather than a commercial package with a familiar update channel.
Version 7.0.1 Is the Immediate Fix, but Validation Matters
CISA’s remediation is direct: update the NASA Core Flight System Health & Safety application to version 7.0.1. NASA’s public GitHub release page identifies cFS v7.0.1 as the current release and shows it was published in May 2026, ahead of CISA’s July 16 advisory.That timing matters. Organizations may already have the corrected version available in their source-management workflow without having incorporated it into their mission-specific builds. In aerospace and industrial environments, however, “update available” is not the same as “update deployed.” A patch can require compatibility testing against the Core Flight Executive, operating-system abstraction layer, platform support package, mission apps, message definitions, and existing telemetry expectations.
The practical response should begin with an inventory rather than an indiscriminate upgrade. Teams should identify HS source trees, built artifacts, simulator images, hardware-in-the-loop labs, and any inherited cFS bundles that include a pre-7.0.1 release. They should also determine whether Housekeeping Telemetry commands are reachable from networks beyond a tightly controlled operations segment.
For deployments that cannot be immediately rebuilt or requalified, the compensating controls are familiar but important:
- Restrict access to command and telemetry interfaces to authorized operational networks.
- Remove unnecessary exposure between development, business, lab, and mission-control segments.
- Require controlled remote access paths rather than directly publishing management interfaces.
- Review logs and restart behavior to ensure an HS crash is detected, recorded, and handled without masking the triggering condition.
- Validate that a patched build correctly handles both normal and malformed telemetry requests before placing it into an operational image.
The CVSS Vector Should Not Be Mistaken for Internet Exposure
The advisory’s CVSS v3.1 vector assigns network attack complexity as low and privileges required as none. That is a useful warning that the affected request path should not be treated as trustworthy simply because it is routine. It does not, by itself, establish that cFS devices are exposed to the public internet or that an unauthenticated outsider can reach every deployment.Exposure depends on each implementation’s command routing, network architecture, radio or ground-link design, authentication layers, and operational procedures. A lab simulator on a shared engineering network carries a different risk profile from an isolated flight-software target reachable only through controlled ground infrastructure.
That nuance should shape remediation priorities. Internet-facing or broadly routed test systems deserve immediate attention, especially if they accept telemetry-related traffic from networks that include unmanaged developer machines, contractors, or shared services. More isolated systems still need the update, but their scheduling can be governed by mission assurance, regression testing, and maintenance windows.
The absence of known public exploitation should likewise be read as a status report, not a reason to defer action. Public proof-of-concept code is not required for a simple availability flaw to become operationally disruptive.
A Narrow Bug With an Unusually Important Failure Mode
CVE-2026-15352 is not a sprawling compromise scenario. CISA has not reported confidentiality or integrity impact, and the advisory does not claim an attacker can seize control of a cFS deployment. The risk is simpler: a request that should be routine can terminate an application tasked with monitoring health, events, watchdog activity, and CPU aliveness.For teams operating NASA cFS Health & Safety builds older than 7.0.1, the priority is to locate the deployed version, test the updated software against mission-specific integrations, and close unnecessary access to telemetry interfaces in the meantime. The next meaningful milestone is not the advisory itself—it is whether version 7.0.1 has made it into the actual images and systems that operators rely on.
