GHSA-w87v-7w53-wwxv
HIGHApollo Embedded Sandbox and Explorer vulnerable to CSRF via window.postMessage origin-validation bypass
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
@apollo/sandbox📦@apollo/explorerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Impact
A Cross-Site Request Forgery (CSRF) vulnerability was identified in Apollo’s Embedded Sandbox and Embedded Explorer.
The vulnerability arises from missing origin validation in the client-side code that handles window.postMessage events. A malicious website can send forged messages to the embedding page, causing the victim’s browser to execute arbitrary GraphQL queries or mutations against their GraphQL server while authenticated with the victim’s cookies.
Who is impacted
Anyone embedding Apollo Sandbox or Apollo Explorer in their website may have been affected by this vulnerability.
- Users who embed Apollo Sandbox or Apollo Explorer in their websites via npm packages (
@apollo/sandboxand@apollo/explorer) or direct links to Apollo’s CDN. - Users running Apollo Router with embedded Sandbox enabled. This served the vulnerable code from Apollo’s CDN.
- Users running Apollo Server with embedded Sandbox or Explorer enabled. Embedded Sandbox is enabled by default when
NODE_ENVis not set toproduction, and embedded Sandbox and Explorer can also be enabled in production mode via landing page plugins. This served the vulnerable code from Apollo’s CDN.
While all of the above methods of serving Embedded Sandbox and Explorer were vulnerable, Apollo has already updated its CDN to remove all vulnerable versions. Unless you install the npm package @apollo/sandbox or @apollo/explorer directly into your website’s front end code, no action is necessary: the vulnerability has already been mitigated.
Users who do not embed Sandbox/Explorer on their websites, or who only run Apollo Router/Server with production defaults were never impacted. The use of non-embedded Sandbox and Explorer hosted on studio.apollographql.com is not vulnerable.
Scope of impact
The vulnerability allows a malicious website to open the vulnerable website in a new window and force it to send GraphQL requests to its origin. The requests themselves are not "cross-origin" as they are directly issued from the vulnerable website, but their contents are dictated by the malicious website.
The malicious website cannot read the responses to the GraphQL operations, but the operations may be mutations with side effects (such as using credentials to update app-specific data access controls). These operations can contain the browser user's cookies, and the vulnerable website may be on a private network otherwise inaccessible to the attacker. Operations sent this way look and exactly like legitimate operations sent by a human interacting with the embedded Sandbox or Explorer.
Patches
The issue has been fixed by adding strict origin validation to DOM message handling.
@apollo/sandbox: Patched in v2.7.2 and later@apollo/explorer: Patched in v3.7.3 and later- Apollo’s CDN embeds have been updated to patched versions. This protects embeds based on
<script>tags pointing to Apollo’s CDN, as well as the Apollo Router and Apollo Server features. No action is necessary to adopt the fix in this case.
If you manually edited the <script> tag provided by the Explorer or Sandbox UI to replace the version string _latest, v2, or v3 with a specific git-style SHA, you may find that the Explorer or Sandbox UI does not currently load. To fix this, use a supported URL instead, as documented for Sandbox or Explorer. (The third-party Go GraphQL server gqlgen provides a function ApolloSandboxHandler which serves an unsupported URL and was broken by our mitigations; upgrading to gqlgen v0.17.81 will resolve this issue.)
Workarounds
- If you are using Apollo Server, ensure
NODE_ENV=productionis set in production to avoid unintentionally serving embedded Sandbox. - Customers not using embedded Sandbox/Explorer are not affected and do not need to take action.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @apollo/sandbox | all versions | 2.7.2 |
| 📦npm | @apollo/explorer | all versions | 3.7.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @apollo/sandbox. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @apollo/sandbox to 2.7.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w87v-7w53-wwxv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w87v-7w53-wwxv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w87v-7w53-wwxv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w87v-7w53-wwxv in your dependencies?
O3 detects GHSA-w87v-7w53-wwxv across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.