GHSA-9Q82-XGWF-VJ6H: XS-Search and CSRF Prevention Bypass in Apollo Server

Apollo Server implements built-in protections against Cross-Site Request Forgery (CSRF) and Cross-Site Search (XS-Search) attacks. These protections rely heavily on the browser's implementation of the Cross-Origin Resource Sharing (CORS) protocol, specifically the preflight request mechanism. The server expects that any cross-origin request with a non-safelisted Content-Type will be preceded by an HTTP OPTIONS request.

The vulnerability exists within the HTTP request parsing logic of @apollo/server. The implementation incorrectly assumed that the presence of a non-safelisted Content-Type header inherently proved that a CORS preflight request had already been executed and approved by the browser. This assumption creates an attack surface when interacting with browsers that deviate from the CORS specification.

An attacker exploiting this vulnerability can force an authenticated user's browser to execute read-only GraphQL queries against the Apollo Server. While direct data extraction is prevented by standard cross-origin read blocking, the attacker can leverage timing differences to infer the results of these queries. This information disclosure constitutes an XS-Search attack.

The root cause of this vulnerability lies in a flawed state-machine assumption regarding the robustness of browser-enforced CORS policies. Apollo Server evaluates the Content-Type of incoming requests to determine if they are "safe." Safelisted types include text/plain, application/x-www-form-urlencoded, and multipart/form-data.

If a request arrived with a Content-Type outside of this safelist, Apollo Server's logic determined that the browser must have already performed a preflight check. The server trusted that if the request reached the processing stage, the origin had been authorized by the CORS policy. Consequently, the server proceeded to execute the GraphQL query.

This logic fails when accounting for a known bug in at least one major browser. This browser allows cross-origin HTTP GET requests with specific non-safelisted Content-Type headers, such as message/rfc822, to be transmitted without triggering the mandatory OPTIONS preflight request.

Because the browser fails to enforce the preflight, the malicious GET request reaches the Apollo Server intact. The server processes the message/rfc822 header, incorrectly assumes a successful preflight has occurred, and executes the authenticated query on behalf of the attacker's cross-origin site.

The vulnerability was remediated in commit ada12001c4e95b5c779d80314a5a32e33087b5cf by introducing strict MIME type validation for incoming GET requests. Prior to this patch, Apollo Server did not validate the specific value of the Content-Type header on GET requests if it assumed a preflight check had passed.

The patched code in packages/server/src/runHttpQuery.ts now enforces that if a GET request contains a Content-Type header, it must explicitly parse to application/json. Because HTTP GET requests do not contain a body, the presence of alternative MIME types indicates anomalous behavior.

case 'GET': {
  const contentType = httpRequest.headers.get('content-type');
  if (contentType !== undefined) {
    const contentTypeParsed = MIMEType.parse(contentType);
    if (
      contentTypeParsed === null ||
      contentTypeParsed.essence !== 'application/json'
    ) {
      throw new BadRequestError(
        'GET requests may not have a content-type header other than application/json.',
        { extensions: { http: newHTTPGraphQLHead(415) } },
      );
    }
  }
  // ... proceed to parse search parameters
}

If the validation fails, the server immediately throws a BadRequestError and returns an HTTP 415 Unsupported Media Type status. This mechanism rejects the request before any GraphQL processing occurs, neutralizing the XS-Search vector regardless of browser-level CORS preflight anomalies.

Exploitation requires the attacker to host a malicious website and convince an authenticated user to visit it. The target user must possess an active session with the vulnerable Apollo Server instance. This session is typically maintained via HTTP cookies or HTTP Basic Authentication, which the browser automatically attaches to cross-origin requests.

Upon loading the malicious page, the attacker's JavaScript initiates a cross-origin HTTP GET request to the target Apollo Server's GraphQL endpoint. The script explicitly sets a non-safelisted Content-Type header, using a value like message/rfc822 or message/http.

Due to the underlying browser bug, the browser bypasses the CORS preflight requirement for this specific MIME type. The browser directly transmits the GET request to the vulnerable server, including the victim's authentication credentials. The server receives the request, incorrectly validates the CSRF protection state based on the header, and executes the query.

The attacker utilizes JavaScript timing functions (e.g., performance.now()) to measure the exact duration of the cross-origin request. By sending specific GraphQL queries that take varying amounts of time depending on the backend data state, the attacker can infer the victim's sensitive information piece by piece, completing the XS-Search attack.

The primary impact of this vulnerability is information disclosure via read-only CSRF, categorized as an XS-Search attack. An attacker can extract sensitive data from the GraphQL API without ever directly reading the HTTP response. The severity is highly dependent on the nature of the data exposed through the GraphQL endpoint.

This vulnerability does not allow an attacker to perform state-changing operations (mutations). Apollo Server implements separate protection layers that strictly require POST requests and validate payloads for operations that modify data. Therefore, the integrity and availability of the server and its database remain unaffected.

Confidentiality is the sole affected vector. Attackers can iterate through boolean queries to extract data. For example, an attacker can query whether a specific invoice exists, whether a user has administrative privileges, or whether a personal attribute matches a given string. The precision of the timing attack limits the exfiltration rate but reliably yields data over time.

The definitive remediation for this vulnerability is upgrading all instances of @apollo/server and @apollo/server/standalone to version 5.5.0 or later. The patch introduces the necessary strict MIME type validation for GET requests directly into the core HTTP parsing logic.

For environments where an immediate upgrade is not feasible, organizations can implement mitigation controls at the network edge. Web Application Firewalls (WAF) or reverse proxies can be configured to inspect incoming HTTP GET requests destined for the GraphQL endpoint.

Specifically, security engineers should deploy rules that reject any GET request containing a Content-Type header that is not exactly application/json. Requests matching this drop criteria should be explicitly blocked with an HTTP 415 status code to replicate the behavior of the official patch and neutralize the browser-level bypass.