GHSA-3wgp-x9p5-c7cc is a medium-severity (CVSS 6.5) Cross-site Scripting (XSS) vulnerability in @appium/base-driver. O3 Security confirms whether GHSA-3wgp-x9p5-c7cc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Appium: Reflected XSS / arbitrary JS in @appium/base-driver /test/guinea-pig* routes
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.
How urgent is this, really
GHSA-3wgp-x9p5-c7cc plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 367,327 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
@appium/base-driverReal-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
Summary
Appium's base-driver mounts the built-in /test/guinea-pig, /test/guinea-pig-scrollable and /test/guinea-pig-app-banner routes unconditionally on every server. The handler reflects the throwError query param, the comments POST field, and the User-Agent request header into the returned HTML via compileLodashTemplate, which interpolates <%= expr %> as String(expr) with no HTML/JS escaping. This yields reflected XSS, and the throwError value is reflected inside a <script> block, giving arbitrary JavaScript execution on the server's origin. No authentication, no session, no driver and no plugin are required, and the default bind address is 0.0.0.0.
Details
Affected
@appium/base-driver10.6.0 (with Appium server 3.5.0); tested live.- Template engine helper:
@appium/base-driverlib/utils.tscompileLodashTemplate.
Location (file:line)
- Routes mounted unconditionally:
base-driver/lib/express/server.ts:216-219(app.all('/test/guinea-pig', guineaPig)etc.). - Tainting:
base-driver/lib/express/static.ts:35-61(guineaPigTemplate) —throwError = String(req.params.throwError ?? req.query?.throwError),params.comment = String(req.body.comments),params.userAgent = req.headers['user-agent']. - Unescaped render:
base-driver/lib/utils.ts:67-83(compileLodashTemplate) emits<%= expr %>asString(${expr})vianew Function(...), no escaping. - Sinks (shipped templates):
base-driver/static/test/guinea-pig.html:11-12(throwErrorinside<script>),:50(comment),:87(userAgent); same inguinea-pig-scrollable.html/guinea-pig-app-banner.html.
PoC
Requests:
GET /test/guinea-pig?throwError=x%27%2balert(document.domain)%2b%27
POST /test/guinea-pig (body: comments=</span><img src=x onerror=alert(1)>)
GET /test/guinea-pig (header: User-Agent: <script>alert(7)</script>)
Impact
An attacker who can get a victim to open a crafted link (or auto-submit a form) to the Appium server executes arbitrary JavaScript on the server's origin. With default CORS * + no authentication, that JS can drive the WebDriver REST API and plugin endpoints. The endpoints are debug/test fixtures that should not be reachable on a production listener at all.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @appium/base-driver | all versions | 10.7.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @appium/base-driver. 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 @appium/base-driver to 10.7.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3wgp-x9p5-c7cc 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-3wgp-x9p5-c7cc 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-3wgp-x9p5-c7cc. 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-3wgp-x9p5-c7cc in your dependencies?
O3 detects GHSA-3wgp-x9p5-c7cc across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.