GHSA-4852-vrh7-28rf is a high-severity (CVSS 7.4) Cross-site Scripting (XSS) vulnerability in graphql-playground-html. O3 Security confirms whether GHSA-4852-vrh7-28rf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Reflected XSS in GraphQL Playground
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
graphql-playground-htmlnpmDescription
Impact
directly impacted:
graphql-playground-html@<1.6.22- all unsanitized user input forrenderPlaygroundPage()
all of our consuming packages of graphql-playground-html are impacted:
graphql-playground-middleware-express@<1.7.16- unsanitized user input toexpressPlayground()graphql-playground-middleware-koa@<1.6.15- unsanitized user input tokoaPlayground()graphql-playground-middleware-lambda@<1.7.17- unsanitized user input tolambdaPlayground()graphql-playground-middleware-hapi@<1.6.13- unsanitized user input tohapiPlayground()
as well as any other packages that use these methods with unsanitized user input.
not impacted:
graphql-playground-electron- usesrenderPlaygroundPage()statically for a webpack build for electron bundle, no dynamic user inputgraphql-playground-react- usage of the component directly in a react application does not expose reflected XSS vulnerabilities. only the demo inpublic/contains the vulnerability, because it uses an old version of the html pacakge.
Patches
upgrading to the above mentioned versions will solve the issue.
If you're using graphql-playground-html directly, then:
yarn add graphql-playground-html@^1.6.22
or
npm install --save graphql-playground-html@^1.6.22
Then, similar steps need to be taken for each middleware:
Workarounds
Ensure you properly sanitize all user input for options you use for whatever function to initialize GraphQLPlayground:
for example, with graphql-playground-html and express:
const { sanitizeUrl } = require('@braintree/sanitize-url');
const qs = require('querystringify');
const { renderPlaygroundPage } = require('graphql-playground-html');
module.exports = (req, res, next) => {
const { endpoint } = qs.parse(req.url)
res.html(renderPlaygroundPage({endpoint: sanitizeUrl(endpoint) })).status(200)
next()
}
or, with graphql-playground-express:
const { expressPlayground } = require('graphql-playground-middleware-express');
const { sanitizeUrl } = require('@braintree/sanitize-url');
const qs = require('querystringify');
const { renderPlaygroundPage } = require('graphql-playground-html');
module.exports = (req, res, next) => {
const { endpoint } = qs.parse(req.url)
res.html(expressPlayground({endpoint: sanitizeUrl(endpoint) })).status(200)
next()
}
References
Credits
Masato Kinugawa of Cure53
For more information
If you have any questions or comments about this advisory:
- Open an issue in graphql-playground
- Email us at [email protected]
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | graphql-playground-html | all versions | 1.6.22 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for graphql-playground-html. 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 graphql-playground-html to 1.6.22 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4852-vrh7-28rf 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-4852-vrh7-28rf 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-4852-vrh7-28rf. 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-4852-vrh7-28rf in your dependencies?
O3 detects GHSA-4852-vrh7-28rf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.