In August 2026, security researchers disclosed a critical vulnerability in NASA and JPL’s AIT-GUI ground control software. The flaw made it possible for an unauthenticated attacker to issue commands to spacecraft and instruments and even run scripts without ever logging in.
The root cause was missing authentication and weak access controls on a web-based console. That’s the kind of issue security teams see in ordinary applications every day, but the stakes change completely when the system on the receiving end is real hardware in orbit that costs millions in public funds.
The incident is a reminder that testing source code alone is not enough. Cyber teams also need to understand how an application behaves once it is running. That’s where DAST tools come in.
DAST Tools Test Applications the Way Attackers See Them
Dynamic application security testing, or DAST, is a type of scan that checks applications as they’re running, rather than simply looking at their source code.
A DAST tool sends requests to the application in a way similar to a real user, or a cyber criminal. It then observes how the application responds to identify behavior that reveals an exploitable weakness.
Static scans can only see so much. A whole set of problems can emerge once the code is actually running and interacting with databases, APIs, and other services.
That’s what happened with AIT-GUI. The console likely passed a code review without any clear issues. The problem only became visible once the application was live. It turns out the console was accepting unauthenticated commands.
Runtime Testing Can Expose Authentication and Access-Control Problems
The NASA case was a pinpoint example of an access-control failure. Sensitive endpoints, the ones that could issue commands to spacecraft, were reachable without any login at all.
DAST is built to catch exactly this. It can walk through a login flow and test whether it holds up. It can try to reach protected functionality without valid credentials. It can check session handling, testing whether tokens expire properly or get reused when they shouldn’t.
It can also flag endpoints that were never meant to be public but ended up reachable anyway, which is what happened with AIT-GUI.
These types of issues can’t be caught by reading the code alone. You must also test how the application responds when receiving real requests.
Modern Applications Require API Security Testing
Another important takeaway from the NASA case is the prevalence of APIs and the importance of securing them. Specifically, the flaws sat in the API endpoints that gave the console its ability to execute commands and scripts.
That is how modern apps work. Instead of one monolithic application, most systems run on a web of APIs talking to each other and to outside clients. Each one of them is a potential entry point. Left exposed, any one of these endpoints could put everything it connects to at risk.
That risk is already playing out at scale. A 2026 report found that 87% of organizations experienced an API-related security incident in 2025, with the average number of daily API attacks per organization more than doubling year over year.
DAST tools test APIs the same way as web applications. They probe it without credentials to see if it lets them in anyway, feed it input it was not meant to handle, and watch closely for how it reacts. What they’re after is any behavior that only reveals itself once the API is live and fielding real traffic.
Had that kind of testing run against AIT-GUI before release, the missing authentication on those endpoints would have surfaced early. Instead, it took a live, exposed system to bring the flaw to light.
High-Impact Systems Need Defense in Depth
The NASA vulnerabilities are nothing new. These are the types of flaws that security teams deal with all the time. But rarely do they carry consequences like this. A compromised ground control system can mean billions of dollars in hardware, years of mission planning, and research that can’t simply be redone if something goes wrong.
To protect their systems, organizations need a defense-in-depth approach. DAST is part of that, but it’s not the whole picture. Code review and SAST (static testing) catch issues sitting in the source. Penetration testing adds human judgment to complement automated checks. Authentication controls and network restrictions limit what an attacker can reach in the first place.
DAST picks up exactly where these other checks stop. It’s the only check that actually watches the application behave. And it needs to run constantly, not just once.
Applications change all the time, so running DAST as part of CI/CD and against staging environments means new runtime issues get caught as the application evolves.
Conclusion
This incident is a great reminder that security testing can’t stop at the source code. DAST exists precisely because applications behave differently once they’re live, connected to other systems, and reachable by real requests.
You don’t have to be a rocket scientist at NASA for this to matter. For a company whose business runs on a web app, a missing authentication check or an exposed endpoint can be just as devastating as it was for AIT-GUI.
- NASA Ground Control Cyber Issue Shows Why DAST Tools Still Matter - September 28, 2026
- What Makes a DLP Solution Effective for Remote Teams? - July 25, 2026
- How to Use Threat Intelligence Reports to Make Better Security Decisions - July 15, 2026
