Summary by iaramsri
Responsible Disclosure Report - NASA VDP
Unauthenticated XPATH Error-Based SQL Injection in NASA Space Place API
Executive Summary
On August 11, 2026, I identified and responsibly reported an Unauthenticated error-based SQL injection vulnerability affecting a publicly accessible NASA Space Place API endpoint:
POST /api/experiment/answer/new/
The vulnerability was caused by the application's handling of HTTP form parameter names.
User-controlled parameter names were incorporated into the SQL INSERT column list without being sufficiently restricted to a predefined set of expected database fields.
By supplying a specially crafted parameter name, it was possible to modify the structure of the generated SQL statement and cause the underlying database server to evaluate attacker-controlled SQL expressions.
The vulnerability was responsibly reported through the NASA Vulnerability Disclosure Program (VDP) via Bugcrowd.
The submission was subsequently reviewed and remediated and was officially marked Resolved on August 19, 2026.
On August 20, 2026, NASA issued an official Letter of Recognition (LOR) acknowledging the responsible security research and contribution.
Internal database identifiers, authentication tokens, full SQL injection payloads, and unnecessary implementation details have intentionally been omitted from this public disclosure.
Affected Component
Application: NASA Space Place
Affected endpoint:
POST /api/experiment/answer/new/
Authentication required: None
The endpoint formed part of the application's publicly accessible experiment-answer submission workflow.
Vulnerability Details
The vulnerable endpoint dynamically constructed an SQL INSERT statement using HTTP form parameter names as database column identifiers.
Conceptually, the vulnerable behavior was similar to:
$sql = "INSERT INTO <table> (" .
implode(",", array_keys($_POST)) .
") VALUES (...)";
When unexpected parameter names are accepted without strict validation, an attacker may be able to supply SQL syntax instead of a legitimate database column name.
In this case, a specially crafted parameter name could modify the structure of the generated INSERT statement and introduce attacker-controlled SQL expressions.
This demonstrates an important SQL injection scenario where the vulnerable input exists in the parameter name rather than the parameter value.
Proof of SQL Execution
Controlled testing demonstrated that SQL expressions supplied through the crafted parameter name were parsed and evaluated by the underlying database server.
Error-based techniques were used to safely return a limited amount of fixed database metadata through attacker-controlled markers.
For example, responses followed patterns similar to:
XPATH syntax error: '~BD:[REDACTED]~'
and:
XPATH syntax error: '~BU:[REDACTED]~'
The markers surrounding the returned values were supplied by the testing request, while the values themselves were produced by database runtime functions.
A separate controlled database-object resolution test also confirmed that an application database column could be successfully referenced from an attacker-controlled subquery.
These tests demonstrated that the issue was not merely producing malformed SQL or a generic syntax error.
The injected SQL expressions were being evaluated by the database server.
Specific database names, database account identifiers, schema details, and full injection payloads have been intentionally omitted.
Potential Impact
Successful exploitation could allow an unauthenticated attacker to execute attacker-controlled SQL expressions and SELECT subqueries under the privileges assigned to the application's database account.
Depending on the permissions available to that account, potential consequences could include:
- Unauthorized access to database information.
- Enumeration of database schema and application objects.
- Retrieval of application data accessible to the database account.
- Potential modification of application data where write permissions are available.
- Additional impact depending on the database configuration and assigned privileges.
Testing was intentionally stopped after confirming controlled SQL execution and limited metadata access.
The maximum possible impact against production data was not tested.
Root Cause
The root cause was the use of user-controlled HTTP parameter names as dynamically generated SQL identifiers.
The application did not sufficiently restrict submitted parameter names to a fixed set of known fields before incorporating them into the SQL query structure.
This allowed a crafted parameter name to modify the intended SQL statement.
The vulnerability also demonstrates why traditional prepared statements are not sufficient when attacker-controlled input determines SQL identifiers.
Parameterized queries protect SQL values, but dynamically generated identifiers such as column names must instead be statically defined or validated against a strict allowlist.
Remediation Recommendations
The recommended remediation is to avoid dynamically constructing SQL column lists from submitted HTTP parameter names.
The application should:
- Define the accepted fields statically within the application.
- Strictly allowlist expected HTTP parameter names.
- Reject or ignore unexpected form parameters.
- Use prepared statements and bound parameters for all submitted values.
- Ensure client-controlled input cannot determine SQL identifiers.
- Generate server-controlled metadata such as timestamps and request information exclusively on the server.
- Avoid returning generated SQL statements to API clients.
- Suppress raw database error messages from public responses.
- Store detailed database errors only in protected server-side logs.
- Review similar create/update handlers for the same dynamic parameter-to-column pattern.
Timeline
- August 11, 2026 — Vulnerability identified and reproduced through a fresh unauthenticated workflow.
- August 12, 2026 — NASA acknowledged the report and referred it to the appropriate security and system teams.
- August 12, 2026 — NASA confirmed that a Letter of Recognition would be awarded once the finding was resolved.
- August 19, 2026 — Submission marked Resolved on Bugcrowd.
- August 20, 2026 — NASA issued an official Letter of Recognition (LOR).
Resolution and Recognition
The vulnerability was responsibly disclosed through the NASA Vulnerability Disclosure Program via Bugcrowd.
Following investigation and remediation, the submission was officially marked:
Resolved — August 19, 2026
NASA subsequently issued a Letter of Recognition on August 20, 2026, recognizing the responsible identification and reporting of the vulnerability.
The exact internal remediation implementation has not been publicly documented and is therefore not speculated upon in this disclosure.
Ethical Statement
This research was performed within the scope and requirements of NASA's Vulnerability Disclosure Program.
Testing was limited to what was necessary to demonstrate the vulnerability.
No production user records, credentials, personal information, or other sensitive application data were retrieved.
No destructive testing was performed.
Internal database identifiers, full exploitation payloads, tokens, and other unnecessary implementation details have been intentionally omitted from this public disclosure.
Purpose of Disclosure
The goal of this disclosure is to highlight an unusual but important SQL injection pattern:
SQL injection through attacker-controlled HTTP parameter names rather than parameter values.
Applications may correctly parameterize submitted values while still remaining vulnerable if untrusted input is used to construct SQL identifiers or query structure.
Secure database interaction therefore requires protection of both:
- SQL values through parameterized queries.
- SQL identifiers and structure through static definitions and strict allowlisting.
This vulnerability was responsibly reported, investigated, remediated, and resolved through coordination between an independent security researcher, Bugcrowd, and NASA.
Researcher: Itthidej Aramsri
Program: NASA - Vulnerability Disclosure Program via Bugcrowd
Vulnerability: Unauthenticated XPATH Error-Based SQL Injection
Status: Resolved
Resolved: August 19, 2026
NASA Letter of Recognition: August 20, 2026