Outdated Vue.js Library Has a Known Security Flaw (CVE-2018-6341)
Your website is using an old version of Vue.js (a JavaScript library that powers your web pages) that has a known security flaw. The flaw only affects sites that render pages on the server before sending them to visitors — a common setup for faster-loading or SEO-friendly sites. If your site works this way and passes user-supplied data into page attributes, the flaw could allow a malicious user to inject unwanted code into your pages. Upgrading Vue.js to a newer version fully resolves this.
Business Impact And Actions
medium urgencyBusiness Impact
If exploited, this flaw could allow an attacker to inject malicious scripts into pages viewed by your users — potentially stealing session data or performing actions on their behalf. This could expose you to customer trust issues, regulatory scrutiny under data protection laws (such as GDPR), and reputational damage. The risk is conditional: it only applies if your site uses server-side rendering and passes unsanitised user input through dynamic attribute bindings.
What To Do
- Ask your developer to check whether your site uses server-side rendering (SSR) with Vue.js — this determines whether the risk is active.
- Ask your developer to upgrade the Vue.js package to version 2.5.17 or later (or ideally to the latest Vue 2.x release). This is a straightforward dependency update.
- If an immediate upgrade is not possible, ask your developer to audit any places in the code where user-supplied data is passed into Vue's v-bind directive during server-side rendering, and sanitise that input.
- Consider scheduling a broader review of your JavaScript dependencies to catch other outdated libraries at the same time.
Vue.js < 2.5.17 — XSS via Unsanitised Spread Attributes in SSR (CVE-2018-6341)
medium severity CVSS 6.1Vulnerability Explanation
In Vue.js versions prior to 2.5.17, the server-side rendering (SSR) engine did not sanitise attribute names when processing object spread bindings via v-bind (e.g., `<div v-bind="obj">`). An attacker who can control the keys of the bound object can inject arbitrary HTML attribute strings — including sequences like `foo="bar"></div><script>alert(1)</script>` — directly into the server-rendered HTML output. Because the SSR renderer serialises attribute names without validation, the injected payload is written verbatim into the HTML string sent to the client, resulting in stored or reflected XSS depending on how the bound data originates.
Root Cause
The SSR attribute rendering module (`src/platforms/web/server/modules/attrs.js`) iterated over all keys of a v-bind spread object and emitted them as raw HTML attribute names without checking for unsafe characters. The fix introduced an `isSSRUnsafeAttr` guard that skips any attribute key containing characters that could break out of the HTML attribute context.
Technical Impact
An attacker who can influence the keys of a v-bind object in a server-rendered Vue component can inject arbitrary HTML or JavaScript into the page delivered to end users. This enables session hijacking via cookie theft, credential phishing via DOM manipulation, or delivery of malicious payloads to all users who receive the affected server-rendered page.
Severity Justification
Exploitability requires the attacker to control object keys passed to a v-bind spread in an SSR context — not a universal condition. Impact is standard reflected/stored XSS. CVSS 6.1 is consistent with typical reflected XSS scores (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).
Affected Components
vue < 2.5.17vue-server-renderer < 2.5.17
Remediation Steps
- Upgrade the `vue` and `vue-server-renderer` packages to 2.5.17 or later. Ideally, upgrade to the latest Vue 2.x release (2.7.x): `npm install vue@^2.7 vue-server-renderer@^2.7` or `yarn upgrade vue vue-server-renderer`.
- If you cannot upgrade immediately, audit all SSR components for `v-bind` spread usage (i.e., `<element v-bind="someObject">`) where `someObject` keys may originate from user input, and sanitise those keys before binding.
- After upgrading, run your existing test suite and verify SSR output does not regress. The fix is non-breaking.
- Consider migrating to Vue 3, as Vue 2 reached end-of-life in December 2023 and no longer receives security patches.
Verification Steps
- Run `npm list vue` or `yarn list vue` and confirm the installed version is 2.5.17 or higher.
- In your SSR output (e.g., via `renderToString`), pass a test object with a key containing `></div><script>alert(1)</script>` as a v-bind spread value and confirm the script tag does not appear in the rendered HTML.
- Check the Vue changelog or `node_modules/vue/package.json` to confirm the installed version.
Code Examples (html)
// Vue < 2.5.17 — attacker-controlled key escapes HTML context
// data: { attrs: { 'foo="bar"></div><script>alert(1)</script>': '' } }
<div v-bind="attrs"></div>
// SSR output (UNSAFE): <div foo="bar"></div><script>alert(1)</script></div>
// Vue >= 2.5.17 — isSSRUnsafeAttr() skips dangerous keys
// Same data input now produces safe output:
// SSR output (SAFE): <div></div>
// Upgrade in package.json:
{
"dependencies": {
"vue": "^2.7.16",
"vue-server-renderer": "^2.7.16"
}
}
Best Practices
- Never pass unsanitised user input as the keys of a v-bind spread object in SSR components — validate or allowlist attribute names at the application layer.
- Keep Vue and its companion packages (`vue-server-renderer`, `@vue/server-renderer`) pinned to the latest patch release and include them in your dependency audit schedule.
- Implement a Content Security Policy (CSP) header as a defence-in-depth measure to limit the impact of any XSS that does occur.
- Since Vue 2 is end-of-life, plan a migration to Vue 3 to continue receiving security fixes.
Found this in your infrastructure?
VulWall scans for this and dozens of other issues automatically.
Scan Your Domain Free