The Patch You Can’t Push
Why AI Is About to Break Space Cybersecurity
Late last year, a small AI security startup called AISLE pointed an automated code-review tool at CryptoLib, the cryptographic library that wraps nearly every command NASA (and some other commercial satellite operators) sends to spacecraft on orbit. In just four days, they discovered a serious vulnerability in code that had been in the wild for 3 years. The bug (CVE-2025-59534) was a command injection in the library’s authentication path and had been missed by human review over three years in a codebase that ships to some of the highest-stakes systems we operate in orbit. And while NASA patched it within weeks and the case got written up as a success story for AI in cybersecurity, it also surfaces a strategic problem that doesn’t have an obvious answer: AI is rapidly compressing the time it takes to find a vulnerability, but in space, the time it takes to fix one hasn’t budged.
The Discovery Curve Got Shorter
The bug itself is straightforward: CryptoLib built a login command for its key-management server by gluing together two strings from its own configuration, an operator username and a path to a credentials file, and the would hand the result to the operating system. If either string contained shell metacharacters, anything after them runs as a command. An attacker who can edit CryptoLib’s configuration, through a compromised operator account or a tampered mission-prep workstation or a supply-chain insertion, can run code with whatever privileges the library has. What’s particularly notable here, though is that the bug survived three years of human code reviews, but was found in four days by pointing a model at the right repository.
This pattern is playing out across the cybersecurity landscape, from Anthropic’s Project Glasswing to OpenAI’s Daybreak. The bottleneck for securing a system is shifting – not that long ago, vulnerability discovery often drove the operational tempo, but the pace of discovery is skyrocketing, driven in part by mountains of low-quality AI-written code flooding open source projects and enterprise ecosystems and also by the pace at which AI systems can discover novel vulnerabilities in existing codebases.
For most software, the new math is still mostly manageable, since hotfixes can deploy in hours (though that gap is growing). Space doesn’t work that way.
The Patch Curve Did Not
You can’t push CryptoLib v1.4.2 to an on-orbit satellite the way you push a hotfix to a server. Uplink bandwidth for spacecraft is metered, and you generally need to wait for the vehicle to be in line of sight of a ground station antenna or a relay, limiting update windows to small temporal periods over specific geographies. Any change to flight software is also a much riskier operation than redeploying a service: the vehicle is irreplaceable and a rollback path may not exist, which means that a failure or bug in an update could brick your multi-million-dollar satellite and cause immediate, cascading service disruptions depending on the satellite’s mission.
This all compounds into a structural patch latency several orders of magnitude longer than what software security in any other domain experiences. While a known CVE on a server can get patched in a sprint, a known CVE on a satellite may sit there, advertised by its own disclosure, while operators evaluate uplink risk, regression-test on engineering models, and wait for a communications window. In cyber terms, the vehicle sits at a known address with a known unpatched flaw for months.
CVE-2025-59534 itself didn’t have that problem, since CryptoLib is ground software, and NASA patched it on a normal ground-software timeline, but the next CVE in this class might live in flight code that has already shipped on a vehicle that has been on orbit for years.
What the Adversary Sees
The same AI tools that found this vulnerability are available to nearly any regular customer. CryptoLib is open source, as is the flight-software stack of plenty of smaller missions, and so are big chunks of the bus and payload software the commercial space industry runs on, which the Department of Defense now depends on for a growing share of its space-based capability. A nation-state actor running the same kind of automated review against the same codebases will surface its own list of vulnerabilities, and won’t feel obligated to disclose them.
The CryptoLib story proves out this fundamental attacker/defender asymmetry: on discovery, defenders and attackers are both operating at machine speed, but once a vuln is discovered, defenders are forced to operate at flight-software speed and attackers at exploit-development speed. The gap between those two numbers presents a strategic risk to some of our most sensitive systems: navigation systems, secure global communications, and intelligence collection from orbit.
Pre-Launch Is the Best Lever Left
If the patch curve can’t move (very much), the response must come earlier in the lifecycle. The most obvious (and operationally lightest-lift) move is making AI-augmented code review a standing requirement in the pre-launch security pipeline. AISLE only found CVE-2025-59534 because they proactively pointed their model at the right repo, but similar tools should be running against every flight-software baseline, including the substantial body of inherited code that ships from mission to mission without much review and updates to those libraries before they ship. The Space Force’s expanded cyber requirements for commercial providers are one natural vehicle, as are the security gates inside NASA’s Class B and Class C processes.
A harder move is formally verifying the security envelope around the command-and-telemetry path (the software that handles commands going up to a spacecraft and data coming back down). Formal verification means mathematically proving that a piece of code does exactly what its specification says and nothing else. Done well, it forecloses entire classes of bugs, including the class CVE-2025-59534 belongs to. Formal verification adds time and cost to development, and was therefore often only applied to the most safety-critical systems, like avionics. Better tools and AI-assisted proof work have changed that calculation for narrow, well-defined components. Compromising command/telemetry enables an attacker to gain control of the entire spacecraft. Verifying that segment still might leave bugs in the rest of the flight software, but it closes off the worst-case attack (the one that ends with someone else flying your hardware).
The most difficult, but also most consequential, change is to fundamentally alter how we think about architecting security for space systems. On-orbit systems must be designed for a world where a known, unpatched vulnerability will exist for months and the vehicle still has to do its job. That means real least-privilege between flight-software components, command authentication rooted in hardware that doesn’t depend on any single library being correct, and a safe mode that limits the attack surface while a patch is being prepared.
All of these levers are susceptible to the inevitable improvement in model capability that will find new vulns that earlier reviews missed - I don’t have a solution for future-proofing beyond what we know LLMs to be able to do. I’d love your suggestions.
What to Watch
1. Whether NASA, the Space Force, NRO, or Congress fold AI-augmented review into the security gates on flight-software acquisitions.
2. Whether the next CVE in this class lands in flight code instead of ground code, and how the program that owns it handles the disclosure and mitigation.
3. Whether commercial providers carrying national-security payloads, particularly the proliferated LEO constellations DOD is now operationally dependent on, get to pre-launch AI review faster than the government does, and what that means for who ends up setting the assurance standard.
4. Congressional or Executive interest in understanding US exposure to on-orbit cyber vulnerabilities and how to mitigate operational barriers to remediation.
Issue #1 was about how AI is changing the knowledge business, and this one is about what happens when the same technology runs into the slowest-patching infrastructure we operate.
If you have a view on where this is going, particularly from the space, cyber, or acquisition side, I want to hear it. The best signal usually comes from the people closest to the noise.