CVE-2026-71214 in PlanDev
Summary
by MITRE • 08/05/2026
The Aerie/PlanDev sequencing-server's authorization middleware (sequencing-server/src/app.ts) derives the caller's Hasura session role via getHasuraSession(), which prefers a session_variables object taken directly from the client-supplied JSON request body over the Authorization header's JWT claims, with no verification that the request actually originated from Hasura. By setting {"session_variables":{"x-hasura-role":"aerie_admin"}} in the body of a request to POST /command-expansion/put-expansion with no Authorization header, an unauthenticated attacker satisfies the role check and can insert arbitrary expansion rules into sequencing.expansion_rule, which govern how spacecraft activities are translated into commands. Separately, POST /put-dictionary is explicitly listed in the ENDPOINTS_WHITELIST and is exempt from any authentication, allowing unauthenticated writes of command dictionaries.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability represents a critical authorization bypass in the Aerie/PlanDev sequencing-server system that stems from improper session role derivation and insufficient authentication controls. The core flaw exists in the getHasuraSession() function within sequencing-server/src/app.ts which demonstrates a dangerous preference for client-supplied session_variables over legitimate JWT claims, creating an avenue for privilege escalation through crafted request bodies. The middleware architecture fails to validate that incoming requests genuinely originate from Hasura itself, instead accepting potentially malicious session data directly from the request payload without proper cryptographic verification or source authentication.
The technical implementation exposes two distinct attack vectors that together create a complete path to unauthorized administrative access. The first vulnerability allows unauthenticated attackers to manipulate the x-hasura-role parameter within session_variables to assume the aerie_admin role by simply including {"session_variables":{"x-hasura-role":"aerie_admin"}} in their POST request body to /command-expansion/put-expansion endpoint. This bypasses all authentication mechanisms because the system trusts the client-provided session data without verification, effectively allowing privilege escalation from anonymous to administrative privileges through a simple JSON payload modification.
The second vulnerability compounds this issue by exposing the /put-dictionary endpoint as explicitly whitelisted in ENDPOINTS_WHITELIST and completely exempt from authentication requirements. This endpoint allows arbitrary writes to command dictionaries which form the foundation of spacecraft command translation processes, meaning attackers can not only gain administrative privileges but also directly modify core system functionality that governs how spacecraft activities translate into actual commands. The combination of these vulnerabilities creates a complete attack chain where an unauthenticated user can escalate privileges through the session variable manipulation and then use the exposed dictionary endpoint to inject malicious command definitions.
The operational impact of this vulnerability extends far beyond simple unauthorized access, as it allows attackers to fundamentally alter how spacecraft operations are executed by manipulating expansion rules that govern command generation. This represents a severe security risk for space mission operations where command accuracy is critical, potentially allowing adversaries to cause system malfunctions, data corruption, or even unsafe operational conditions. The vulnerability aligns with CWE-284 (Improper Access Control) and CWE-352 (Cross-Site Request Forgery) categories, while the attack pattern follows ATT&CK techniques such as T1078 (Valid Accounts) and T1566 (Phishing) through privilege escalation mechanisms. The lack of source verification for session data represents a fundamental flaw in the security architecture that violates the principle of least privilege and trust-on-first-use anti-patterns.
Mitigation strategies must address both the immediate vulnerability in session variable handling and the broader authentication exemption issue. Organizations should implement cryptographic verification of client requests to ensure they genuinely originate from Hasura, establish proper request source validation mechanisms, and remove endpoints from the whitelist that do not require explicit authentication. The system should enforce strict input validation on session_variables parameters, requiring cryptographic signatures or other forms of authentication verification before accepting role claims. Additionally, all endpoints should undergo mandatory authentication checks with appropriate access control lists, and the sequencing-server configuration should be reviewed to ensure no unintended whitelisting occurs. Implementing proper request origin verification and enforcing minimum security requirements for all API endpoints will prevent similar vulnerabilities from occurring in the future while maintaining system functionality for legitimate users.