We’ve been here before. A technology becomes critical infrastructure. The engineers building it are competent and focused on making it work. The organisations funding it have deadlines and KPIs that reward shipping on time. And somewhere in all of that, the assumption takes root that physical or logical distance equals protection.
In hospitals it looked like Windows XP on machines wired to life-critical equipment, on networks that were supposedly isolated and never really were. In industrial control systems it looked like PLCs with default credentials reachable from the internet, because nobody expected anyone to look. In IoT it looked like anyone with thirty euros and a UART adapter pulling firmware out of devices sitting in half a million homes, finding hardcoded credentials and bugs that had been solved everywhere else for twenty years.
Space is making the same bet. The hardware is up there, tens of thousands of kilometres away, moving at several kilometres per second. Nobody’s going to reach it. Right?
The structural problem nobody wants to name
The engineers building satellite systems are not incompetent. That needs saying clearly, because when vulnerabilities appear the temptation is to find someone to blame and land on whoever wrote the code.
What’s happening is harder to fix. NASA is a public agency tied to government budget cycles and procurement processes designed for a different era. The software running on missions launched today may have been written years ago, under different threat models, by teams that no longer exist. The decisions that look obviously wrong in hindsight were made under real pressure, with real deadlines, by people trying to get a spacecraft into orbit.
This isn’t an excuse. It’s a diagnosis.
And there’s a constraint unique to this domain that makes the diagnosis worse. In every other field, patching is the answer. In space, the technically correct decision is often not to touch validated software. Flight software is validated at enormous cost and expected to stay in operation for the full lifetime of the mission. A patch means re-validating, re-testing, and accepting the risk that the fix introduces a regression in a system you can never physically reach. No other domain carries that constraint into its security model.
So software frameworks powering critical systems accumulate vulnerabilities across years and missions. NASA’s Core Flight System, cFS, is a concrete example. It’s been used on more than forty NASA missions and adopted by the European Space Agency, JAXA, the Canadian Space Agency and others. It runs on everything from small CubeSats to the James Webb Space Telescope. In March 2025, VisionSpace published a vulnerability assessment of cFS Aquila and found critical issues: path traversal in the OSAL module, remote code execution through a GOT overwrite in the Memory Management Module, denial of service from malicious telecommands. Multiple CVEs, published, attributed, real.
It’s worth being precise about what this is and what it isn’t. cFS is open source, and its vulnerability lifecycle worked exactly the way it’s supposed to: findings published, CVEs assigned, patches and recommendations issued. That’s not evidence of a broken disclosure culture. It’s evidence of the size of the attack surface, software written years ago, validated at cost, now expected to stay operational for the full lifetime of its missions.
Then, separately and independently, an unauthenticated remote code execution turned up in NASA cFS Software Bus Network over UDP, affecting release Draco v7.0.1. That one is currently under responsible disclosure with INCIBE, with an incident reference assigned on 3 September 2026 (reference withheld), and remains under embargo pending vendor coordination. Different version, different researcher, same software family. There’s a disclosure note at the end of this article.
VisionSpace did their job. More issues were waiting anyway. That’s not a failure of the auditors. It’s a demonstration of how large the surface is.
The false security of distance
Here’s what looks like protection but isn’t: satellites are far away, but they’re not disconnected. Every satellite in operation has a ground segment on Earth that sends commands, receives telemetry and pushes software updates. That ground segment lives in buildings, on networks, run by people with email accounts and VPN credentials and the same attack surface as any other organisation.
The attack on Viasat’s KA-SAT on 24 February 2022, the same day Russia began its invasion of Ukraine, showed this directly. Tens of thousands of modems across Europe and Ukraine went offline. It cut Ukrainian military communications at a critical moment and knocked out 5,800 wind turbines in Germany that ran on the same network. The wiper reached customer terminals through the network’s own management and provisioning infrastructure. The satellite itself was untouched. The spacecraft and the ground station control chain weren’t the target. The compromise sat one layer lower, in the distribution chain between operator and end user, which is exactly what makes it instructive. The attacker didn’t need to reach the satellite. They reached everything the satellite depended on.
There’s a second layer that’s less obvious. Satellites can receive software updates over their command link. On-orbit patching is a real capability, used by ESA, NASA and commercial operators. That’s good, because it means vulnerabilities found after launch can in theory be fixed. It’s also a problem, because the update mechanism itself is an attack surface. If the ground control infrastructure is compromised, the update channel becomes a way to inject malicious code into a system you can never physically reach.
Security through distance was never real. It was a working assumption that nobody sufficiently motivated would try. That assumption is getting harder to defend.
Two threats, not one
State-level actors going after operational infrastructure, the Viasat pattern, exploit procurement, management networks and trusted update channels, and need resources only governments or their proxies can commit. Independent researchers and hobbyists do something different: they expand the population of people examining the software and protocols at all. The first group proves the surface is already contested. The second is why the volume of findings will keep climbing. Both matter. They’re not the same problem and they don’t have the same solution.
The niche is opening up
Getting into this domain used to need agency-level resources. A launch contract, a ground station, specialised hardware, teams of engineers. That’s changing.
PwnSat (pwnsat.org) is the clearest sign of the shift. Created by Kevin León and built by the PwnSat team with Electronic Cats over several years of research, it’s a platform vulnerable by design: a real satellite architecture, with its protocols, Mission Operation Center, Ground Station and FlatSat hardware, built on purpose to be exploited. It implements CCSDS over LoRa and AX.25. Kevin Leon Morales presented it at the Open Source CubeSat Workshop in Athens in October 2025, and Romel Marín, a senior pentester and aerospace security researcher, brought PwnSat 2.0 to Black Hat USA Arsenal in August 2026. It’s open source, vulnerable by design, and cheap enough to ship to your door for a low triple-digit price.
This is the same moment IoT went through when anyone with a cheap UART adapter could start pulling firmware out of the devices in their house. The manufacturers hadn’t gotten worse at security. There were just more people looking. The CVEs came on their own.
Space is there now. And the surface is a lot larger.
Before the window closes
None of this is unsolvable, and that’s exactly what makes this moment a choice rather than a destiny.
Cryptographic authentication for telemetry and command links already exists as a standard, CCSDS SDLS, and it isn’t uniformly deployed. Ground segment networks can be segmented and monitored like the critical infrastructure they are. Public procurement for space systems can carry explicit security requirements, the way defence procurement increasingly does. Independent researchers can be handed a legal and practical way to report what they find, instead of discovering that the easiest channel is a conference talk.
The vulnerabilities are documented. The tools to find more cost less than a games console. The cases proving this surface is already being actively exploited are in the headlines. The window where these fixes are cheap is the one we’re in right now. It won’t stay open out of habit.
Disclosure
One vulnerability described in this article, an unauthenticated remote code execution in NASA Core Flight System (cFS) Software Bus Network (SBN) over UDP, affecting release Draco v7.0.1, was identified by the author and reported to INCIBE (Spanish National Cybersecurity Institute), with an incident reference assigned on 3 September 2026 (reference withheld). It’s currently under a responsible disclosure embargo. Technical details and proof-of-concept material are withheld pending vendor coordination. The issue remains unpatched at the time of writing.