Skip to content

← Public intelligence

npm package

@vue/server-renderer

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.2npmAmendedPublished

    @vue/server-renderer: XSS via missing CR in attribute-name blacklist

    GHSA-g2v6-rqmx-r4w6

    Affected
    • npm @vue/server-renderer < 3.5.42; >= 3.6.0-rc.0, < 3.6.0-rc.6
    Fixed in
    3.6.0-rc.63.5.42· Vendor fix available
    Issue
    @vue/server-renderer was investigated specifically because it's the one place in Vue where template rendering output becomes a real HTTP response body -- a genuine server-side trust boundary, unlike client-side rendering which only ever affects the same browser session that's already running the app's own JS. ssrRenderAttrs() (in packages/server-renderer/src/helpers/ssrRenderAttrs.ts) is what compiled SSR output calls for something like <div v-bind="userObject". It loops over the object's own keys and, for each one, renders it as an HTML attribute: The value always goes through escapeHtml() -- that part is correctly and consistently applied everywhere in this file. But the attribute name (attrKey) is only checked against a character blacklist, then spliced directly into the output with no escaping of its own: That blacklist covers: , /, =, ", apostrophe, tab (U+0009), line feed (U+000A), form feed (U+000C), and space (U+0020). It does not cover U+000D -- carriage return…

    Recommended action: Upgrade to 3.6.0-rc.6 (pre-release) or 3.5.42 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →