How severe is GHSA-mp6q-xf9x-fwf7?

GHSA-mp6q-xf9x-fwf7 has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-mp6q-xf9x-fwf7?

GHSA-mp6q-xf9x-fwf7 affects the following packages: apollo-server (npm), @apollo/server (npm), @apollo/server (npm). Ecosystems affected: npm.

How do I fix GHSA-mp6q-xf9x-fwf7?

A fix is available for GHSA-mp6q-xf9x-fwf7; check the affected-versions list above or the advisory for the patched release of apollo-server, then make sure no transitive dependency still pins the vulnerable range.

How do I detect GHSA-mp6q-xf9x-fwf7 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apollo-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-mp6q-xf9x-fwf7 if there is no patch (or I can't update yet)?

Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Is GHSA-mp6q-xf9x-fwf7 actively exploited in the wild?

No public exploit code has been indexed for GHSA-mp6q-xf9x-fwf7 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-mp6q-xf9x-fwf7?

GHSA-mp6q-xf9x-fwf7 has an EPSS (Exploit Prediction Scoring System) score of 0.7%, placing it in the 53th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-mp6q-xf9x-fwf7?

GHSA-mp6q-xf9x-fwf7 is classified as CWE-1333 (CWE-1333). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-mp6q-xf9x-fwf7 published, and has it been updated?

GHSA-mp6q-xf9x-fwf7 was published on February 4, 2026 and was last updated on February 4, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

HIGH severity

Apollo Serve vulnerable to Denial of Service with `startStandaloneServer`GHSA-mp6q-xf9x-fwf7

HIGHFix: apollographql/apollo-server@d25a5bd

GHSA-mp6q-xf9x-fwf7 is a high-severity (CVSS 7.5) CWE-1333 vulnerability in apollo-server. A fix is available for apollo-server — see the affected versions and patch details below.

Also known asCVE-2026-23897

Published

Feb 4, 2026

Updated

Feb 4, 2026

Affected

3 pkgs

Patched

2 / 3

Exploits

None indexed

Exploitation data as of Nov 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-mp6q-xf9x-fwf7.

EPSS Exploitation Probability

via FIRST.org ↗

0.7%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs53th percentile — riskier than 53% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

3 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.

apollo-servernpm

175Kdownloads / week

@apollo/servernpm

4.0Mdownloads / week

Description

Impact

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.

Who is impacted

Users directly using startStandaloneServer from @apollo/server/standalone.

This issue affects Apollo Server from v5.0.0 through v5.3.x.

It also affects all releases of the end-of-life major versions v4, v3, and v2. Although Apollo Server v4 is EOL and Apollo no longer commits to providing support or updates for it, a fix for it was released in v4.13.0. Apollo Server v3 and v2 are no longer updated, as they have been EOL since 2024 and 2023 respectively.

Patches

Patches for this issue are released as @apollo/server versions 5.4.0 and 4.13.0.

In accordance with RFC 7159, these versions now only accept request bodies encoded in UTF-8, UTF-16 (LE or BE), or UTF-32 (LE or BE). Any other character set will be rejected with a 415 Unsupported Media Type error. Note that the more recent JSON RFC, [RFC 8259 (https://datatracker.ietf.org/doc/html/rfc8259#section-8.1), is more strict and will only allow UTF-8. Since this is a minor release, we have chosen to remain compatible with the more permissive RFC 7159 for now. In a future major release, the restriction may be tightened further to only allow UTF-8.

Workarounds

Users of apollo-server v2 or v3 that cannot upgrade for some reason could switch from the standalone apollo-server package to an integration package like apollo-server-express or apollo-server-koa and set up their own server. Please note that these old packages are generally EOL and do not receive any more support or bug fixes. This can only be seen as a short-term workaround. Updating to @apollo/server v5 should be a priority.

Affected Packages

3 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`apollo-server`	≥ 2.0.0	No fix
📦npm	`@apollo/server`	≥ 4.2.0&&< 4.13.0	4.13.0`npm install @apollo/server@4.13.0`
📦npm	`@apollo/server`	≥ 5.0.0&&< 5.4.0	5.4.0`npm install @apollo/server@5.4.0`

Affected Products

1 product · 3 configurations

Application

apollo serverapollographql

≥ 5.0.0 && ≤ 3.13.0

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for apollo-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
A fix is available for GHSA-mp6q-xf9x-fwf7; check the affected-versions list above or the advisory for the patched release of apollo-server, then make sure no transitive dependency still pins the vulnerable range.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Impact 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`. ### Who is impacted Users directly using `startStandaloneServer` from `@apollo/server/standalone`. This issue affects Apollo Server from v5.0.0 through v5.3.x. It