Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

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

Also known asCVE-2020-4038
Published
Jun 9, 2020
Updated
Jul 8, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jul 8, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

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.

55other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
graphql-playground-htmlnpm
902Kdownloads / week

Description

Impact

directly impacted:

  • graphql-playground-html@<1.6.22 - all unsanitized user input for renderPlaygroundPage()

all of our consuming packages of graphql-playground-html are impacted:

  • graphql-playground-middleware-express@<1.7.16 - unsanitized user input to expressPlayground()
  • graphql-playground-middleware-koa@<1.6.15 - unsanitized user input to koaPlayground()
  • graphql-playground-middleware-lambda@<1.7.17 - unsanitized user input to lambdaPlayground()
  • graphql-playground-middleware-hapi@<1.6.13 - unsanitized user input to hapiPlayground()

as well as any other packages that use these methods with unsanitized user input.

not impacted:

  • graphql-playground-electron - uses renderPlaygroundPage() statically for a webpack build for electron bundle, no dynamic user input
  • graphql-playground-react - usage of the component directly in a react application does not expose reflected XSS vulnerabilities. only the demo in public/ 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:

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmgraphql-playground-htmlall versions1.6.22

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

### Impact **directly impacted:** - `graphql-playground-html@<1.6.22` - all unsanitized user input for `renderPlaygroundPage()` **all of our consuming packages** of `graphql-playground-html` are impacted: - `graphql-playground-middleware-express@<1.7.16` - unsanitized user input to `expressPlayground()` - `graphql-playground-middleware-koa@<1.6.15` - unsanitized user input to `koaPlayground()` - `graphql-playground-middleware-lambda@<1.7.17` - unsanitized user input to `lambdaPlayground()` - `graphql-playground-middleware-hapi@<1.6.13` - unsanitized user input to `hapiPlayground()` as wel
O3 Security · Impact-Aware SCA

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.