Rapid7 patches GraphQL injection flaw in Bulk Export MCP server
A tool argument passed straight into a query string let crafted input append extra GraphQL selections, but only within the operator's own API scope.
By The Agentic Times ·

Rapid7 has fixed a GraphQL query injection flaw in its Bulk Export MCP server, tracked as CVE-2026-97228 and published to the US National Vulnerability Database on 25 September 2026. Versions 0.2.5 through 0.6.1 are affected. The fix is in version 0.6.2.
According to the NVD entry, the problem sits in the export-status component, specifically the get_export_status function in src/export_manager.py. An export_id value arrives there as an MCP tool argument, by way of the check_rapid7_export_status and download_rapid7_export tools, and is interpolated directly into the GraphQL query string without validation. MCP, the Model Context Protocol, is the interface that lets an AI agent call tools such as these.
The practical effect is straightforward. The advisory says an export_id containing quote and brace characters can close the intended export(id: "...") selection early and append attacker-controlled selections at the root of the query, schema introspection being the example given. The result is a single well-formed GraphQL document, which is then sent to the Rapid7 export API using the operator's own API key.
Rapid7 is clear about the limits of the issue. The advisory states that the flaw does not grant an existing actor any access they do not already have. Every injected query runs inside the operator's own already-authenticated API scope, with the operator's own valid key, and cannot cross a tenant or account boundary. An operator who simply wanted to run those queries could call the API directly and achieve the same thing.
The realistic exposure, the advisory says, is a compromised or careless upstream MCP client, or indirect prompt injection that forwards an unvalidated identifier. Indirect prompt injection is where instructions hidden in content an agent reads are treated as commands. In that scenario, the agent would be the one supplying the malformed export_id, and the server would faithfully splice it into a query and run it with real credentials.
The fix in 0.6.2 takes the standard approach. According to the advisory, export_id is now passed as a parameterised GraphQL variable, declared as $exportId: ID!. Passing values as variables rather than building the query text by concatenation means user-supplied characters are treated as data, not as part of the query structure. The advisory lists the 0.6.2 release on the project's GitHub repository as its reference.
The pattern here is a familiar one from web application security, transplanted into agent tooling. String interpolation into a query language is the same class of mistake that produces SQL injection. What changes in an MCP setting is where the untrusted input comes from. Tool arguments are often generated by a language model rather than typed by a person, and that model may have read attacker-controlled text earlier in the same session. Input validation at the tool boundary therefore does work that a human interface might once have done implicitly.
Operators running Bulk Export MCP between 0.2.5 and 0.6.1 should move to 0.6.2. No exploitation in the wild is mentioned in the advisory, and no severity score is quoted in the published entry text.
Sources
- nvd.nist.govhttps://nvd.nist.gov/vuln/detail/CVE-2026-97228
