CVE-2026-23897
Unknown Unknown - Not Provided
Denial of Service in Apollo Server startStandaloneServer via Malformed Requests

Publication date: 2026-02-04

Last updated on: 2026-03-18

Assigner: GitHub, Inc.

Description
Apollo Server is an open-source, spec-compliant GraphQL server that's compatible with any GraphQL client, including Apollo Client. In versions from 2.0.0 to 3.13.0, 4.2.0 to before 4.13.0, and 5.0.0 to before 5.4.0, the default configuration of startStandaloneServer from @apollo/server/standalone is vulnerable to denial of service (DoS) attacks through specially crafted request bodies with exotic character set encodings. This issue does not affect users that use @apollo/server as a dependency for integration packages, like @as-integrations/express5 or @as-integrations/next, only direct usage of startStandaloneServer.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-03-18
Generated
2026-05-07
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
apollographql apollo_server From 4.2.0 (inc) to 4.13.0 (exc)
apollographql apollo_server From 5.0.0 (inc) to 5.4.0 (exc)
apollographql apollo_server From 2.0.0 (inc) to 3.13.0 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-1333 The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-23897 is a high-severity denial of service (DoS) vulnerability in the default configuration of the startStandaloneServer function of the @apollo/server/standalone package.

This vulnerability arises because the server improperly handles specially crafted request bodies that use exotic character set encodings. Attackers can exploit this flaw by sending such requests, causing the server to become unavailable.

The issue affects Apollo Server versions 2.0.0 to 3.13.0, 4.2.0 to before 4.13.0, and 5.0.0 to before 5.4.0, but only when using startStandaloneServer directly. Users employing @apollo/server as a dependency within integration packages like @as-integrations/express5 or @as-integrations/next are not impacted.

To fix this, patched versions enforce strict validation of request body encodings, accepting only UTF-8, UTF-16 (little or big endian), or UTF-32 (little or big endian) encoded JSON bodies, rejecting others with a 415 Unsupported Media Type error.


How can this vulnerability impact me? :

This vulnerability can impact you by allowing an attacker to cause a denial of service (DoS) on your Apollo Server instance when using the startStandaloneServer function with its default configuration.

Specifically, an attacker can send specially crafted request bodies with exotic character set encodings that the server mishandles, leading to server unavailability.

This means your server could become unresponsive or crash, disrupting service availability to legitimate users.

The vulnerability does not affect confidentiality or integrity of data, but availability is highly impacted.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability arises from the default configuration of the startStandaloneServer function in Apollo Server, which improperly handles specially crafted request bodies with exotic character set encodings. Detection involves identifying if your system is running a vulnerable version of Apollo Server using startStandaloneServer (versions 2.0.0 to 3.13.0, 4.2.0 to before 4.13.0, and 5.0.0 to before 5.4.0).'}, {'type': 'paragraph', 'content': 'To detect exploitation attempts or the vulnerability, you can monitor incoming HTTP requests for unusual or exotic character set encodings in the Content-Type header, especially those that are not UTF-8, UTF-16, or UTF-32. Requests with unsupported charsets may indicate attempts to trigger the denial of service.'}, {'type': 'paragraph', 'content': 'Suggested commands include using network monitoring or packet capture tools (e.g., tcpdump, Wireshark) to filter HTTP requests with Content-Type headers containing charset parameters other than UTF-8, UTF-16, or UTF-32. For example, using tcpdump to capture HTTP headers:'}, {'type': 'list_item', 'content': "tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep -i 'Content-Type'"}, {'type': 'paragraph', 'content': 'Additionally, checking your application logs for HTTP 415 Unsupported Media Type errors can help identify if the patched server is rejecting requests with unsupported charsets, which may indicate attempted exploitation.'}, {'type': 'paragraph', 'content': 'Finally, verifying the version of Apollo Server in use and whether startStandaloneServer is employed directly is critical, as only direct usage of startStandaloneServer is vulnerable.'}] [1, 2, 3]


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade Apollo Server to a patched version where this vulnerability is fixed. Specifically, upgrade to version 4.13.0 or later in the 4.x series, or version 5.4.0 or later in the 5.x series of @apollo/server.

These patched versions enforce strict validation of request body character encodings, accepting only UTF-8, UTF-16 (little or big endian), or UTF-32 (little or big endian), and reject others with a 415 Unsupported Media Type error, preventing the denial of service attack.

If upgrading is not immediately possible and you are using versions 2.x or 3.x, a temporary workaround is to switch from using the standalone server package to integration packages such as apollo-server-express or apollo-server-koa, which are not affected by this vulnerability.

For production environments, it is recommended to deploy Apollo Server integrated with robust web server frameworks like Express, Koa, or Fastify to gain enhanced control over security configurations.

Monitoring and rejecting requests with unsupported character set encodings at the network or application level can also help mitigate exploitation attempts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart