Researchers at Ben-Gurion University of the Negev have logged 2,827 security findings across 126 public open-source satellite software repositories, and two of the vulnerability classes they describe already carry live CVE entries in flight software running today.
Open-source frameworks have spread quickly through the smallsat sector as teams swap expensive heritage code for free, reusable flight software maintained by comparatively small groups of contributors. The Ben-Gurion team's study, titled An Empirical Security Analysis of Open-Source Software Used in Onboard Satellite Systems, puts a number on that tradeoff for the first time. Researchers ran each repository through a pipeline combining software bill-of-materials generation, software composition analysis, static application security testing, infrastructure-as-code scanning, and secret detection.
Authors Roee Idan, Tomer Cohen Galor, Asaf Shabtai, and Yuval Elovici report that 72 percent of the findings rate medium severity or higher, and that 81.4 percent sit in code the project teams wrote themselves rather than in imported third-party dependencies. The underlying pipeline, called SCA-SAT, was first demonstrated at DEF CON 34.
The pattern holds beyond one dataset. A master's thesis completed at California Polytechnic State University in June 2026 examined 56 public CubeSat code repositories and interviewed eight practitioners, finding inconsistent adoption of basic supply-chain controls such as dependency pinning and code review gates. Inherited code and ad hoc continuous-integration pipelines came up repeatedly as sources of added exposure.
A null pointer in NASA's own flight code
One real example reached the GitHub Advisory Database on July 16, 2026, as GHSA-8472-2q4c-5q85 and CVE-2026-15352. The flaw sits in the Health and Safety application, a plug-in for NASA's Core Flight System that handles application monitoring, event monitoring, and hardware watchdog servicing. A specially crafted Housekeeping Telemetry request triggers a NULL pointer dereference in the application's monitor tables, crashing the process over the network with no authentication required. GitHub rates the bug 8.2 under CVSS v4.
The irony sits close to the surface: the subsystem built to detect other applications failing is the one that failed. Core Flight System code underpins flight software on NASA missions including the Lunar Reconnaissance Orbiter, the Global Precipitation Measurement mission, and the Magnetospheric Multiscale spacecraft, and its open licensing has made it a common choice for university CubeSat teams working on tight budgets.
A contributor using the handle keegan-moore closed the underlying issue with a set of null-pointer-check commits on April 2, 2026, and the fix shipped publicly in the project's v7.0.1 release the following month.
A CubeSat still being built already has a bug
A second disclosure hit software much earlier in its life cycle. CVE-2026-75368, published August 24, 2026, describes a stack overflow in the loadRawData function of the on-board computer software for AcubeSAT, a three-unit CubeSat built by the Greek student team SpaceDot. A crafted ECSS telecommand message can trigger the overflow and crash the onboard software; the bug scores 7.5 under CVSS v3.1 and 8.7 under CVSS v4, and no patched release had been confirmed as of its publication.
AcubeSAT is being developed under the European Space Agency's Fly Your Satellite! education program to study how microgravity and cosmic radiation affect brewer's yeast cells in low Earth orbit. Its on-board computer follows the LibreCube hardware standard and settled on a dual-microcontroller design built around Microchip's SAMV71Q21RT chip, a change the team made after reconsidering an earlier single-processor plan to add redundancy. The spacecraft has not yet flown; the team's most recent public ESA milestone was a 2024 environmental test campaign for its communications subsystem, with no launch date announced as of this month.
The next step is hiding, not crashing
Both disclosed bugs are denial-of-service flaws, the kind of loud failure a ground team notices within minutes. A separate research track argues the more dangerous version of this problem is quiet. The SpyChain paper splits malicious logic across several benign commercial-off-the-shelf payload applications running on a simulated satellite bus, then has them coordinate through a hidden operating-system-level FIFO pipe instead of the cFS Software Bus that ground operators typically monitor for anomalies.
Tested inside NASA's open-source NOS3 satellite simulator, the technique is built to defeat detection approaches modeled on MITRE's SPARTA framework for space-system threats. The paper's authors recommend restricting which system calls payload applications can issue and adding authentication to the software bus itself.
The research moves from paper to live demonstration this month. A researcher presenting under the handle Munara is scheduled to run a talk titled Satellites in the Sandbox: Hands-On Component Collusion and Aerospace C2 Evasion at Hack.lu 2026 in Luxembourg on October 22, including a demo of GNSS-triggered activation and covert telemetry exfiltration over a simulated RF link, followed by a hands-on workshop the next day where attendees build and defend against the same attack inside a virtualized cFS environment.
The Ben-Gurion University study and the SpyChain research were first published on arXiv, with the Hack.lu session detailed on the conference's own schedule.
