GHSA-x8qp-wqqm-57ph
vue-i18n's escapeParameterHtml does not prevent DOM-based XSS through its tag attributes
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
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
vue-i18nnpmDescription
Summary
The escapeParameterHtml: true option in Vue I18n is designed to protect against HTML/script injection by escaping interpolated parameters. However, this setting fails to prevent execution of certain tag-based payloads, such as <img src=x onerror=...>, if the interpolated value is inserted inside an HTML context using v-html.
This may lead to a DOM-based XSS vulnerability, even when using escapeParameterHtml: true, if a translation string includes minor HTML and is rendered via v-html.
Details
When escapeParameterHtml: true is enabled, it correctly escapes common injection points.
However, it does not sanitize entire attribute contexts, which can be used as XSS vectors via:
<img src=x onerror=alert(1)>
PoC
In your Vue I18n configuration:
const i18n = createI18n({
escapeParameterHtml: true,
messages: {
en: {
vulnerable: 'Caution: <img src=x onerror="{payload}">'
}
}
});
Use this interpolated payload:
const payload = '<script>alert("xss")</script>';
Render the translation using v-html (even not using v-html):
<p v-html="$t('vulnerable', { payload })"></p>
Expected: escaped content should render as text, not execute.
Actual: script executes in some environments (or the payload is partially parsed as HTML).
Impact
This creates a DOM-based Cross-Site Scripting (XSS) vulnerability despite enabling a security option (escapeParameterHtml) .
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | vue-i18n | ≥ 9.0.0&&< 9.14.5 | 9.14.5 |
| 📦npm | vue-i18n | ≥ 10.0.0&&< 10.0.8 | 10.0.8 |
| 📦npm | vue-i18n | ≥ 11.0.0&&< 11.1.10 | 11.1.10 |
| 📦npm | @intlify/core | ≥ 9.0.0&&< 9.14.5 | 9.14.5 |
| 📦npm | @intlify/core | ≥ 10.0.0&&< 10.0.8 | 10.0.8 |
| 📦npm | @intlify/core | ≥ 11.0.0&&< 11.1.10 | 11.1.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vue-i18n. 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 vue-i18n to 9.14.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x8qp-wqqm-57ph 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-x8qp-wqqm-57ph 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-x8qp-wqqm-57ph. 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-x8qp-wqqm-57ph in your dependencies?
O3 detects GHSA-x8qp-wqqm-57ph across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.