Summary
apollo-server-core vulnerable to URL-based XSS attack affecting IE11 on default landing page
Workarounds
Disabling the landing page removes the possibility of exploit:
import { ApolloServerPluginLandingPageDisabled } from 'apollo-server-core';
new ApolloServer({
plugins: [ApolloServerPluginLandingPageDisabled()],
// ...
});
See also
A similar issue exists in the landing page of Apollo Router. See the corresponding Apollo Router security advisory.
For more information
If you have any questions or comments about this advisory:
- Open an issue in the Apollo Server repository
- Email us at [email protected]
Credits
This issue was discovered by Adrian Denkiewicz of Doyensec.
Impact
The default landing page contained HTML to display a sample curl command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from window.location.href. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript.
This only affects Apollo Server with the default landing page enabled. Old browsers visiting your server may be affected if ANY of these apply:
- You do not pass any landing page plugin to the
pluginsoption ofnew ApolloServer. - You pass
ApolloServerPluginLandingPageLocalDefault()orApolloServerPluginLandingPageProductionDefault()to thepluginsoption ofnew ApolloServer.
Browsers visiting your server are NOT affected if ANY of these apply:
- You pass
ApolloServerPluginLandingPageDisabled()to thepluginsoption ofnew ApolloServer. - You pass
ApolloServerPluginLandingPageGraphQLPlayground()to thepluginsoption ofnew ApolloServer. - You pass a custom plugin implementing the
renderLandingPagehook to thepluginsoption ofnew ApolloServer.
This issue was introduced in v3.0.0 when the landing page feature was added.
Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
To avoid this, the sample curl command has been removed in release 3.10.1.
Frequently Asked Questions
- What is GHSA-2FVV-QXRQ-7JQ6? GHSA-2FVV-QXRQ-7JQ6 is a medium-severity cross-site scripting (XSS) vulnerability in apollo-server-core (npm), affecting versions >= 3.0.0, < 3.10.1. It is fixed in 3.10.1. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- Which versions of apollo-server-core are affected by GHSA-2FVV-QXRQ-7JQ6? apollo-server-core (npm) versions >= 3.0.0, < 3.10.1 is affected.
- Is there a fix for GHSA-2FVV-QXRQ-7JQ6? Yes. GHSA-2FVV-QXRQ-7JQ6 is fixed in 3.10.1. Upgrade to this version or later.
- Is GHSA-2FVV-QXRQ-7JQ6 exploitable, and should I be worried? Whether GHSA-2FVV-QXRQ-7JQ6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-2FVV-QXRQ-7JQ6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-2FVV-QXRQ-7JQ6? Upgrade
apollo-server-coreto 3.10.1 or later.