CVE-2024-37155: Partial Fix for OpenCTI GraphQL Introspection Bypass

Vulnerability

CVE-2024-37155 affects OpenCTI's custom GraphQL validation logic for blocking schema introspection. According to the advisory and CVE records, unauthenticated attackers could bypass the restriction by altering whitespace and control characters in introspection queries, allowing exposure of the GraphQL schema despite the intended policy. The vulnerable implementation relied on matching a small set of exact substrings such as __schema {, __schema(, __type {, and __type(. That approach is fragile because GraphQL syntax permits formatting variation, so a policy implemented as exact textual fragments can be evaded without changing query semantics. This behavior is documented in the official advisory at GHSA-4MVW-J8R9-XCGC and tracked in MITRE and NVD.

// vulnerable detection logic from graphql.js
const introspectionPatterns = ['__schema {', '__schema(', '__type {', '__type('];
if (introspectionPatterns.some((pattern) => request.query.includes(pattern))) {
  // block request
}

Patch

The patch in commit f87d96918c63b0c3d3ebfbea6c789d48e2f56ad5 replaces the delimiter-sensitive pattern list with broader substring checks for the introspection field names themselves. Instead of requiring exact sequences that include a space or opening parenthesis, the new code flags any query containing __schema or __type. This directly addresses the reported bypass vector based on whitespace and control-character manipulation because those formatting changes no longer affect detection.

// patched detection logic from graphql.js
if (['__schema', '__type'].some((pattern) => request.query.includes(pattern))) {
  // block request
}

Source: GitHub commit, with vulnerability context from the official advisory.

Review

Pros

• The patch clearly fixes the documented bypass class: formatting changes around introspection fields no longer evade the check.
• The implementation is minimal and low-risk from a regression perspective because it only broadens existing matching behavior.
• It aligns with the advisory's stated issue: bypass via whitespace and control-character manipulation is neutralized by removing dependence on exact token-adjacent delimiters.

Cons

• The control is still based on raw string inspection of request.query, not semantic parsing of the GraphQL document. That means enforcement remains outside the GraphQL AST/type system and may still be brittle.
• String matching can overmatch or undermatch depending on transport shape and query construction. For example, it does not demonstrate handling through parsed documents, aliases, fragments, alternate request representations, or future parser behaviors.
• The patch does not show a move to a canonical GraphQL validation rule that rejects introspection semantically; it only widens the blacklist tokens.
• Because the vulnerable mechanism was a custom validation plugin, retaining custom textual filtering preserves the same architectural weakness even if this specific bypass is closed.

Verdict

Partial fix. The patch is effective against the specific vulnerability described in GHSA-4MVW-J8R9-XCGC and CVE-2024-37155: attackers can no longer evade detection merely by changing whitespace or inserting control characters around __schema and __type. However, the fix does not eliminate the root architectural issue, which is enforcing a security policy through ad hoc substring matching rather than AST-level GraphQL validation. For engineering hardening, the better long-term remediation is to reject introspection through parsed query analysis or standard GraphQL validation controls, with tests covering fragments, aliases, encoded transport variants, and malformed-but-parseable formatting edge cases.