![\"NASA](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2025\/11\/1764418214_321_0x0.jpg\")
<\/p>\n<\/p>\n
Researchers reveal NASA vulnerability that went unfixed for three years.<\/p>\n
SOPA Images\/LightRocket via Getty Images<\/p>\n
Security vulnerability researchers have exclusively revealed to me that a critical bug remained hidden in the software protecting communications between NASA spacecraft and Earth for an incredible three years. A successful attacker could, but fortunately didn\u2019t, \u201cinfluence or disrupt spacecraft operations in mission-significant ways,\u201d Stanislav Fort, co-founder and chief scientist at AISLE, the security organization that discovered and responsibly disclosed the vulnerability to NASA, said. Here\u2019s everything you need to know as cybersecurity in space comes under the spotlight.<\/p>\n
ForbesCISA Warns iPhone And Android Users \u2014 Secure Your Smartphone NowBy Davey Winder<\/a>When NASA Authentication Code Becomes A Space Attack Vector<\/p>\n Authentication code is the glue holding many security systems together. Whether you are talking about basic-level two-factor authentication<\/a> as used to help secure our apps, or the more advanced stuff used to encrypt data within things like Windows BitLocker<\/a>.<\/p>\n When it comes to mission-critical software, such as that developed and used by NASA and crucial for protecting the communications between spacecraft and Earth, you would hope that authentication is both highly advanced and highly secure. Yet a critical flaw in CryptoLib, unearthed, pardon the pun, by AISLE\u2019s autonomous analyzer, was uncovered in the authentication path. Tracked as CVE-2025-59534<\/a>, it turned out that the vulnerability had stayed hidden in plain sight for three years, between September 2022 and September 2025. \u201cFor over 1,100 days,\u201d Fort said, \u201cauthentication code meant to secure spacecraft communications contained a command injection vulnerability.\u201dA rapid response by NASA ensured that, upon disclosure, the vulnerability was fixed within four days.<\/p>\n \u201cThe vulnerability transformed what should be a routine authentication configuration into a weapon,\u201d Fort told me in an exclusive interview, adding that \u201can attacker who can control either the username or keytab file path configuration values (perhaps through compromised operator credentials<\/a> or social engineering) can inject arbitrary commands that execute with full system privileges.\u201d If it needs spelling out, when it comes to spacecraft operations, this is particularly dangerous as \u201cthat authentication configuration often happens during mission setup or system maintenance, periods when security vigilance might be focused elsewhere.\u201d<\/p>\n Just how dangerous this security vulnerability was can be seen in the potential havoc it could wreak if exploited. Fort told me that, in very practical terms, this could include:<\/p>\n In practical terms, this could enable:<\/p>\n Access to classified mission data.Injecting false telemetry data or disrupting communications during critical mission phases.Command and control compromise.Compromising the ground infrastructure that connects mission controllers to vehicles in orbitForbesFBI Warns That Hackers Are Posing As Fake Feds \u2014 What You Need To KnowBy Davey Winder<\/a>What You Need To Know About The NASA CVE-2025-59534 Vulnerability<\/p>\n \u201cSpace missions rely on trustworthy cryptography. CryptoLib implements the Space Data Link Security protocol used across NASA missions,\u201d Fort explained, \u201cwhen that layer fails, spacecraft commands, telemetry, and science data are at stake.\u201d CVE-2025-59534 was that weak point. The vulnerable function built a \u2018kinit command string\u2019 from configuration values and executed it via system(). \u201cShell metacharacters in username or keytab\\_file\\_path turned configuration into code,\u201d Fort said, \u201ca design choice that made authentication code an execution vector.\u201d<\/p>\n The reason it could stay undiscovered for so long is that \u201ca familiar system() pattern lived in a CAM\/keytab login path that teams rarely exercise,\u201d I was told, \u201cwhile reviews and tests didn\u2019t include adversarial inputs and configuration was implicitly trusted.\u201d This meant that code review, static analysis, and fuzzing didn\u2019t flag it because it lives in configuration-handling code that looks harmless. \u201cThe triggering inputs are valid config strings with shell meta characters,\u201d Fort explained, \u201cwhich fuzzers<\/a> rarely explore.\u201d<\/p>\n