vue-i18n's escapeParameterHtml does not prevent DOM-based XSS through its tag attributesGHSA-x8qp-wqqm-57ph
Fix: intlify/vue-i18n#2229GHSA-x8qp-wqqm-57ph is a Cross-site Scripting (XSS) vulnerability in vue-i18n. A fix is available for vue-i18n — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-x8qp-wqqm-57ph.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
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.
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.5npm install vue-i18n@9.14.5 |
| 📦npm | vue-i18n | ≥ 10.0.0&&< 10.0.8 | 10.0.8npm install vue-i18n@10.0.8 |
| 📦npm | vue-i18n | ≥ 11.0.0&&< 11.1.10 | 11.1.10npm install vue-i18n@11.1.10 |
| 📦npm | @intlify/core | ≥ 9.0.0&&< 9.14.5 | 9.14.5npm install @intlify/core@9.14.5 |
| 📦npm | @intlify/core | ≥ 10.0.0&&< 10.0.8 | 10.0.8npm install @intlify/core@10.0.8 |
| 📦npm | @intlify/core | ≥ 11.0.0&&< 11.1.10 | 11.1.10npm install @intlify/core@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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is GHSA-x8qp-wqqm-57ph in your dependencies?
Find it across npm, including transitive dependencies.