OpenC3 COSMOS has been flying satellites since 2006. It began as the command and control system for the Space-Based Space Surveillance (SBSS) satellite and was open-sourced in 2014 after becoming, in the words of its developers, "the standard tool for integration and test for the entire company." Today it has documented flight heritage on Capella Space's radar imaging satellites, Kepler Communications' IoT constellation, and FalconSat — the US Air Force Academy's satellite program. Quindar Mission Management, a commercial ground control platform, offers OpenC3 COSMOS as a cloud-hosted service to satellite operators who need command and control without building it themselves. This is the software responsible for satellite command and control operations.

In April 2026, cybersecurity firm VisionSpace published a detailed security assessment of OpenC3 COSMOS v7.0.0. The findings were not theoretical. They were reproducible, step-by-step, with screenshots.

The assessment identified eight categories of vulnerability across the platform's core components: cross-site scripting in the Command Sender UI, path traversal in plugin configuration, plaintext authorization tokens exposed in WebSocket requests, session tokens without expiration, a password reset mechanism that accepts a stolen token as proof of identity, Script Runner access that allows any authenticated user to reach the Redis database, SQL injection in the QuestDB time-series telemetry database, and server-side template injection enabling remote code execution at container level.

None of these represent novel attack vectors. SQL injection has been on the OWASP Top 10 for two decades. Session token mismanagement is a textbook problem. The VisionSpace team found them in a current, actively maintained, production-deployed satellite command and control platform — one updated to version 7.0.0 just weeks before the assessment was published.

This matters because OpenC3 COSMOS is ground segment software: it runs on servers, it is network-connected, and it has operator access to satellite command uplinks. An attacker who compromises it does not need to break into the spacecraft. They can instruct it.

‍

TWO ATTACK SURFACES. TWO DIFFERENT RISK EQUATIONS.

Before assessing the threat, the distinction that most coverage of space cybersecurity misses needs to be stated plainly: the ground segment and the space segment operate under fundamentally different security models, with distinct consequences.

The ground segment — mission control software, TT&C station infrastructure, ground station networks — runs on conventional IT. It can be patched, monitored with SIEM, hardened, and incident-responded to. The VisionSpace findings on OpenC3 COSMOS fall here. They are serious. They are also fixable, if operators act.

The space segment — flight software compiled into spacecraft firmware — does not follow the same rules. Many satellites, particularly those launched before on-orbit patching became standard practice, have no mechanism to receive a software update after deployment. A vulnerability disclosed in that firmware today exists until the spacecraft deorbits. In some cases, that is 2031. In others, longer.

The distinction between "ground" and "space" does not reduce the risk. It clarifies where the leverage points are — and who benefits most from operators failing to secure the infrastructure they can actually control.

‍

THE FOUNDATION NO ONE IS AUDITING

OpenC3 COSMOS is one node in a much larger open-source ecosystem that now runs the space sector's operational infrastructure — and whose security has not kept pace with its adoption.

NASA's F Prime framework, open-sourced in 2017, runs flight software on JPL CubeSats and commercial smallsats. Orbital mechanics calculations across the industry rely on Orekit, a Java library maintained by a nonprofit consortium used by both ESA and commercial operators. Ground station operations run on SatNOGS — the open-source global ground station network that, as of 2024, operates over 500 active stations and has logged more than 11 million satellite observations. ESA used the SatNOGS network to gain initial status observations from its OPS-SAT CubeSat after launch in December 2019. Rogue Space Systems uses SatNOGS operationally for early-orbit tracking. Signal work runs on GNU Radio — the same open-source toolkit that engineers use to track satellites and security researchers use to demonstrate satellite spoofing. And commanding, telemetry, and mission operations run on OpenC3 COSMOS — with SQL injection in its telemetry database and remote code execution via its plugin system.

Almost none of these operators maintain a Software Bill of Materials — an inventory of every open-source component compiled into their systems. Without an SBOM, an operator cannot answer the question: which of our dependencies has a known CVE right now? They are, by definition, flying blind on supply chain risk.

The broader numbers make the structural scale visible. 97% of all applications contain open-source code. 82% of open-source components are classified as inherently risky due to poor maintenance, outdated code, or security flaws. The average enterprise application contains at least 180 third-party components. More than 80% of vulnerable dependencies remain unpatched for more than a year, even when 95% have safer alternatives available.

The average time to remediate a known open-source vulnerability in conventional software was 80 days as of the 2024 Sonatype State of the Software Supply Chain report. Some projects now take 300 to 470 days. For ground segment systems where operators are conservative about changes mid-mission, 80 days is optimistic. For spacecraft firmware without an update pathway, the remediation time is not 80 days. It is the remaining mission lifetime.

‍

THE SCALE PROBLEM: FLEETS, NOT SATELLITES

Here is the threat multiplier that changes the arithmetic entirely.

Modern mega-constellations do not run custom software on each spacecraft. They run the same stack — the same dependencies, the same libraries, the same open-source components — replicated across thousands of nodes simultaneously. Starlink operates more than 6,000 active satellites as of early 2026. Amazon Kuiper is building toward 3,236. OneWeb/Eutelsat operates approximately 600. A single open-source vulnerability shared across a homogeneous fleet is not one satellite's problem. It is a fleet-wide exposure, addressable only if every node can be updated — and addressed on the attacker's timeline, not the defender's.

‍

THE NEW ACCELERANT

What makes this moment different from any previous conversation about space software security is the speed at which AI is widening the gap between vulnerability discovery and remediation — while simultaneously generating the next generation of vulnerable code at industrial scale.

AI tools now detect vulnerabilities faster than ever before, reasoning across entire codebases rather than scanning for known signatures. More discoveries, faster. But the pipeline from discovery to patch to deployment has not accelerated at the same rate. The result is a growing backlog of vulnerabilities that are publicly documented and known to defenders but remain unpatched in production. As security researchers have noted, that gap is about to become more visible, more frequent, and more operationally expensive. For space software running on spacecraft that cannot receive patches, the gap is not expensive. It is permanent.

The second problem is on the generation side. Veracode's 2025 GenAI Code Security Report — testing over 100 large language models across four programming languages — found that AI-generated code contains 2.74 times more vulnerabilities than human-written code, with a 45% failure rate on secure coding benchmarks. Java — the primary language in Orekit and satellite operations software — had the worst performance: a 72% security failure rate. The failure modes are not obscure: authentication errors, privilege escalation paths, hardcoded credentials. Exactly the vulnerabilities VisionSpace found in OpenC3 COSMOS. Exactly the vulnerabilities that matter most when the code commands spacecraft.

The ReversingLabs 2026 Software Supply Chain Security Report found malware in open-source platforms up 73% year-over-year, with attacks increasingly targeting AI development pipelines. Nation-state actors have demonstrated — through years-long operations like the xz Utils compromise, in which a state-linked attacker spent two years building maintainer trust before inserting a backdoor into a compression library embedded in virtually every Linux distribution — both the patience and the capability to embed themselves inside trusted software supply chains long before anyone notices.

‍

Somewhere in orbit right now, there is a satellite running a library with a known CVE. The operator knows. They are weighing the cost and complexity of an on-orbit software update against the assessed probability that anyone will exploit it before the mission ends. In most cases, the mission ends first.

‍

_{Author: Olga Nasibullina, co-founder at THE SIGN}

‍

‍