A web interface that sends commands to spacecraft had no authentication requirement. For nearly a decade, NASA's Advanced Multi-Mission Operations System (AMMOS) Instrument Toolkit Graphical User Interface (AIT-GUI) allowed anyone with network access to issue commands through its HTTP API.
Cycode's security research team discovered the vulnerability chain (GHSA-p9r8-2q67-fp86) in 2024 and worked with NASA on disclosure. The flaws scored 9.4 on CVSS v3.1. Version 2.5.2, released August 12, 2026, included partial fixes, but the advisory published the next day confirmed authentication issues remained unresolved.
This isn't theoretical. If you're running command-and-control software for critical systems, this teardown shows exactly which controls failed and what your team needs to verify today.
Timeline
Pre-2024: AIT-GUI deployed without authentication requirements for command endpoints. The tool handles telemetry processing and command sequencing for spacecraft operations.
2024: Cycode researchers identify missing authentication controls during AI-assisted code analysis of the open-source repository.
August 12, 2026: NASA releases AIT-GUI 2.5.2 with partial security fixes.
August 13, 2026: Security advisory GHSA-p9r8-2q67-fp86 published. No CVE assigned at publication time, complicating tracking across vulnerability databases.
Which Controls Failed
Missing authentication on command endpoints. The HTTP API accepted commands without verifying the requester's identity. Any client with network access could POST command sequences to the interface.
No CSRF protection. Cross-Site Request Forgery vulnerabilities allowed attackers to trick authenticated users into executing malicious commands through crafted web pages. Even if authentication existed elsewhere in the system, CSRF gaps let attackers bypass those checks.
Insufficient input validation. The command interface didn't validate whether incoming requests originated from authorized sources or legitimate sessions.
No session management. Without proper session tokens or state tracking, the system couldn't distinguish between legitimate operators and unauthorized access attempts.
What the Standards Require
OWASP ASVS v4.0.3 Section 2.1 (Authentication General): "Verify that user set passwords are at least 12 characters in length." More critically, Section 2.1.1 requires authentication controls for all application functionality except public resources. Command interfaces for critical systems don't qualify as public resources.
OWASP ASVS Section 4.2 (CSRF): Requirement 4.2.2 states: "Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality." Command execution clearly falls under authenticated functionality.
NIST 800-53 Rev 5 Control IA-2 (Identification and Authentication): "The information system uniquely identifies and authenticates organizational users." For systems controlling spacecraft, this extends to machine-to-machine authentication, not just human users.
ISO 27001 Annex A.9.4.2 (Secure log-on procedures): Organizations must implement authentication mechanisms that prevent unauthorized access. The standard requires verification of user identity before granting access to information processing facilities.
PCI DSS v4.0.1 Requirement 8.3.1 (for any system handling sensitive operations): "Additional authentication factors are used to authenticate access into the cardholder data environment." While AIT-GUI doesn't process payments, the principle applies: critical command interfaces need multi-factor authentication.
The gap here isn't subtle. These standards don't say "consider adding authentication" or "authentication is recommended." They mandate it for any system performing privileged operations.
Lessons for Your Team
Audit command interfaces first. If your system accepts commands via HTTP, gRPC, or any API, authentication isn't optional. Start with your most critical endpoints and work backward.
Run this check today:
# List all endpoints that modify state
grep -r "POST\|PUT\|DELETE" your-api-routes/
# For each one, verify authentication middleware
CSRF protection needs explicit implementation. Don't assume your framework handles it. Django requires {% csrf_token %} in forms. Express.js needs the csurf middleware. Spring needs @EnableWebSecurity with CSRF enabled. Check your configuration files, not the documentation's promises.
AI-assisted code analysis works. Cycode used AI tools to identify these gaps in a large codebase. Your team can run similar scans with tools like Semgrep, CodeQL, or Snyk Code. Configure them to flag missing authentication decorators and CSRF tokens.
Open-source doesn't mean audited. NASA's tool was public for years before anyone reported these flaws. If you're using open-source command-and-control software, don't assume someone else verified the security. The absence of reported vulnerabilities doesn't mean the code is safe.
Partial fixes create false security. Version 2.5.2 addressed some issues but left authentication problems unresolved. When you patch vulnerabilities, verify the fix covers the entire attack surface. Run your exploit proof-of-concept against the patched version.
CVE assignment gaps matter. The advisory noted no CVE was assigned, making it harder for teams to track the vulnerability in their dependency scanners. If you maintain open-source software, request CVEs through MITRE or GitHub's CVE numbering authority. If you consume open-source tools, monitor project advisories directly, not just CVE feeds.
Action Items
Inventory your command interfaces (this week). List every API endpoint, CLI tool, or web interface that executes privileged operations. Include internal tools, not just customer-facing products.
Verify authentication on each endpoint (next sprint). Don't trust inheritance or framework defaults. Test each route with unauthenticated requests and confirm they're rejected.
Enable CSRF protection (next sprint). Add anti-CSRF tokens to all state-changing operations. Test with a simple HTML form that POSTs to your API from a different origin.
Implement session management (next quarter). Use signed tokens (JWT with verification) or server-side sessions with secure cookies. Set appropriate timeouts for command interfaces.
Add authentication to your security checklist (ongoing). Before deploying any new API endpoint, require proof that authentication works. Make it a merge requirement, not a post-deployment audit.
The AIT-GUI vulnerabilities existed for years because no one asked, "Who can access this endpoint?" That's the question your team needs to answer for every command interface you ship.
