fix(deps): update dependency @apollo/server to v5.5.0 [security]#850
fix(deps): update dependency @apollo/server to v5.5.0 [security]#850renovate[bot] wants to merge 1 commit into
Conversation
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #850 +/- ##
=======================================
Coverage 92.19% 92.19%
=======================================
Files 17 17
Lines 397 397
Branches 128 128
=======================================
Hits 366 366
Misses 31 31 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
d4c30c6 to
6b098fa
Compare
6b098fa to
9234445
Compare
9234445 to
9a255d6
Compare
9a255d6 to
2dd3787
Compare
a20ccb3 to
4614f3d
Compare
b2ccaf2 to
3e3b5fa
Compare
3e3b5fa to
31a17b8
Compare
31a17b8 to
333ee31
Compare
This PR contains the following updates:
5.2.0→5.5.0Apollo Serve vulnerable to Denial of Service with
startStandaloneServerCVE-2026-23897 / GHSA-mp6q-xf9x-fwf7
More information
Details
Impact
The default configuration of
startStandaloneServerfrom@apollo/server/standaloneis 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/serveras a dependency for integration packages, like@as integrations/express5or@as-integrations/next, only direct usage ofstartStandaloneServer.Who is impacted
Users directly using
startStandaloneServerfrom@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/serverversions5.4.0and4.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 Typeerror. 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-serverv2 or v3 that cannot upgrade for some reason could switch from the standaloneapollo-serverpackage to an integration package like
apollo-server-expressorapollo-server-koaand 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/serverv5 should be a priority.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Apollo Server: Browser bug allows for bypass of XS-Search (read-only Cross-Site Request Forgery) prevention
GHSA-9q82-xgwf-vj6h
More information
Details
Impact
In a Cross-Site Request Forgery attack, untrusted web content causes browsers to send authenticated requests to web servers which use cookies for authentication. While the web content is prevented from reading the request's response due to the Cross-Origin Request Sharing (CORS) protocol, an attacker may be able to cause side effects in the server ("CSRF" attack), or learn something about the response via timing analysis ("XS-Search" attack).
Apollo Server has a built-in feature which prevents CSRF and XS-Search attacks: it refuses to process GraphQL requests that could possibly have been sent by a spec-compliant web browser without a protective "preflight" step. See Apollo Server's docs for more details on CORS, CSRF attacks, and Apollo Server's CSRF prevention feature.
This feature is fully effective against attacks carried out against users of spec-compliant browsers. Unfortunately, a major browser introduced a bug in 2025 which meant in certain cases, it failed to follow the CORS spec. The browser's maintainers have already committed to fixing the bug and making the browser spec-compliant again.
Even with this bug, Apollo Server's CSRF prevention feature blocks "side effect" CSRF attacks: Apollo Server will still correctly refuse to execute mutations in requests that were not preflighted. However, some specially crafted authenticated GraphQL queries can be issued across origins without preflight in buggy versions of this browser, allowing for XS-Search attacks: an attacker can analyze response times to learn facts about the responses to requests such as whether fields return null or approximately how many list entries are returned from fields.
GraphQL servers are only vulnerable if they rely on cookies (or HTTP Basic Auth) for authentication.
Patches
The vulnerability is patched in
@apollo/serverv5.5.0. This release contains a single change: GraphQL requests sent in HTTPGETrequests which contain aContent-Typeheader naming a type other thanapplication/jsonare rejected. (GETrequests with noContent-Typeare allowed.) This change prevents XS-Search attacks even in browsers which are non-compliant in ways similar to this browser.There are no known cases where GraphQL apps depend on the ability of clients to send non-empty
Content-Typeheaders with GET requests other thanapplication/json, so this change has not been made configurable; if this change breaks a use case, file an issue and more configurability can be added.Apollo is not currently providing a patch for previous major versions of Apollo Server, which are all end-of-life.
Workarounds
If upgrading is not possible, this particular browser's bug can be mitigated by preventing any HTTP request with a
Content-Typeheader containingmessage/from reaching Apollo Server (e.g. in a proxy or middleware).For example, when using Apollo Server's Express integration, something like this can be placed before attaching
expressMiddlewareto theapp:While the patch prevents a broader class of similar issues, the only known way to exploit this vulnerability is against a particular browser which currently plans to ship a fix in May 2026. If it is already past June 2026 and this vulnerability has not been addressed yet, it is likely that the system is not currently vulnerable. Upgrading to the latest version of Apollo Server is still recommended for the broader protection.
Resources
The browser bug causes a similar vulnerability in Apollo Router; see GHSA-hff2-gcpx-8f4p
Severity
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
apollographql/apollo-server (@apollo/server)
v5.5.0Compare Source
Minor Changes
#8191⚠️ SECURITY
ada1200Thanks @glasser! -@apollo/server/standalone:Apollo Server now rejects GraphQL
GETrequests which contain aContent-Typeheader other thanapplication/json(with optional parameters such as; charset=utf-8). Any other value is now rejected with a 415 status code.(GraphQL
GETrequests without aContent-Typeheader are still allowed, though they do still need to contain a non-emptyX-Apollo-Operation-NameorApollo-Require-Preflightheader to be processed if the default CSRF prevention feature is enabled.)This improvement makes Apollo Server's CSRF more resistant to browsers which implement CORS in non-spec-compliant ways. Apollo is aware of one browser which as of March 2026 has a bug which allows an attacker to circumvent Apollo Server's CSRF prevention feature to carry out read-only XS-Search-style CSRF attacks. The browser vendor is in the process of patching this vulnerability; upgrading Apollo Server to v5.5.0 mitigates this vulnerability.
If your server uses cookies (or HTTP Basic Auth) for authentication, Apollo encourages you to upgrade to v5.5.0.
This is technically a backwards-incompatible change. Apollo is not aware of any GraphQL clients which provide non-empty
Content-Typeheaders withGETrequests with types other thanapplication/json. If your use case requires such requests, please file an issue and we may add more configurability in a follow-up release.See advisory GHSA-9q82-xgwf-vj6h for more details.
v5.4.0Compare Source
Minor Changes
d25a5bdThanks @phryneas! -@apollo/server/standalone:The default configuration of
startStandaloneServerwas vulnerable to denial of service (DoS) attacks through specially crafted request bodies with exotic character set encodings.In accordance with RFC 7159, we 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 Typeerror.Note that the more recent JSON RFC, RFC 8259, 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, we may tighten this restriction further to only allow UTF-8.
If you were not using
startStandaloneServer, you were not affected by this vulnerability.Generally, please note that we provide
startStandaloneServeras a convenience tool for quickly getting started with Apollo Server.For production deployments, we recommend using Apollo Server with a more fully-featured web server framework such as Express, Koa, or Fastify, where you have more control over security-related configuration options.
v5.3.0Compare Source
Minor Changes
#8062
8e54e58Thanks @cristunaranjo! - Allow configuration of graphql execution options (maxCoercionErrors)#8014
26320bcThanks @mo4islona! - Exposegraphqlvalidation options.Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.