CVE-2024-45812

What it actually does

Affected Vite builds can emit vulnerable JavaScript when the application is bundled in cjs, iife, or umd output format and uses dynamic asset imports. The generated code derives an import URL from document.currentScript while replacing __VITE_ASSET__ relative paths. Because browser named-element lookup can allow attacker-controlled DOM elements with specific name or id attributes to shadow document.currentScript, an attacker who can inject scriptless HTML can cause the bundle to resolve an attacker-controlled element as the current script. If that element has a malicious src value, the application may dynamically load JavaScript from an attacker-controlled origin, resulting in DOM-based cross-site scripting. Exploitability depends on the vulnerable bundle format and the presence of an HTML injection path that permits unsanitized name or id attributes on otherwise non-script elements.

Why it matters to the business

A successful attack can let an attacker run JavaScript in users' browsers in the context of the affected website, enabling session theft, account actions as the user, data exposure visible to the browser, page defacement, phishing overlays, or abuse of trusted application functionality. The vulnerability is not listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad in-the-wild exploitation is not currently indicated; however, internet-facing applications that allow user-generated HTML are at higher risk because the flaw can turn seemingly harmless markup into executable script. Organizations using Vite widely across frontend applications should treat this as a supply-chain-style build artifact issue: even after upgrading the build tool, deployed static assets remain vulnerable until rebuilt and redeployed.

How an attack unfolds

An attacker first identifies a web page served with a Vite-generated bundle built using an affected Vite version and cjs, iife, or umd output format, particularly one that dynamically imports assets or chunks. The attacker then finds an application feature that stores or reflects user-controlled HTML while blocking script tags but allowing elements such as img and allowing name or id attributes. The attacker submits crafted markup that creates a named DOM element capable of clobbering document.currentScript and supplies a src value that points to attacker-controlled JavaScript. When a victim loads the affected page, the vulnerable Vite bundle resolves the asset URL using the clobbered currentScript reference instead of the real script element. The browser then imports or loads script content from the attacker-controlled location, giving the attacker JavaScript execution in the victim's browser session under the trusted site's origin.

How to fix it

Upgrade Vite to a patched release and rebuild all affected frontend assets. Patched versions are 5.4.6, 5.3.6, 5.2.14, 4.5.5, and 3.2.11, with the upstream fix associated with commit f9691767ad763720065cc7c5c7f369f97b4e7ea8. Because the flaw is present in generated bundles, upgrading the package alone is insufficient: applications must be rebuilt and redeployed so static JavaScript artifacts no longer contain the vulnerable document.currentScript asset-resolution logic. Review build configurations for library output formats cjs, iife, and umd and prioritize those deployments. There are no vendor-provided workarounds, but defense-in-depth mitigations include sanitizing user-supplied HTML to remove or strictly control name, id, and src attributes, disallowing arbitrary HTML where possible, applying a restrictive Content Security Policy that prevents loading scripts from untrusted origins, and using Trusted Types where applicable.

How to confirm the fix worked

Confirm package manifests and lockfiles resolve Vite to a patched version: 5.4.6 or later on the 5.4 line, 5.3.6 or later on the 5.3 line, 5.2.14 or later on the 5.2 line, 4.5.5 or later on the 4.5 line, or 3.2.11 or later on the 3.2 line. Confirm CI/CD rebuilt frontend assets after the Vite upgrade and that deployed JavaScript bundles are newer than the remediation build. Search deployed bundles for vulnerable patterns involving __VITE_ASSET__ replacement and document.currentScript-based URL resolution in cjs, iife, or umd outputs. Review build configuration for output.format values of cjs, iife, or umd and dynamic imports. Test user-controlled HTML rendering paths to ensure elements cannot inject dangerous name or id attributes that shadow document.currentScript. Validate CSP in a browser by confirming script-src does not allow arbitrary remote script origins and that attempted attacker-origin dynamic script loads are blocked.

Typical attack path

1. Fingerprint the application to determine whether it serves Vite-built JavaScript bundles from affected versions and output formats such as cjs, iife, or umd.
2. Identify a page or feature that accepts attacker-controlled HTML, such as comments, posts, profile fields, CMS content, or rich-text input.
3. Verify that script tags are blocked but non-script tags such as img are allowed with unsanitized name or id attributes.
4. Inject DOM-clobbering markup that shadows document.currentScript and sets a src attribute pointing to attacker-controlled JavaScript.
5. Wait for a victim or privileged user to view the affected page containing the injected markup.
6. Trigger the vulnerable Vite-generated dynamic import path so the bundle resolves an asset URL from the attacker-controlled element.
7. Execute attacker-hosted JavaScript in the victim's browser context and use it to read accessible data, perform authenticated actions, or alter page content.

How to detect it

Look for evidence in application logs, WAF logs, CDN logs, content-moderation records, and database-backed audit trails showing submitted or reflected HTML containing non-script elements with suspicious name or id values intended to interfere with currentScript resolution. Prioritize pages that store or display user-generated HTML, including comments, rich-text fields, CMS entries, profile descriptions, tickets, forum posts, and documentation pages. In web access logs and browser telemetry, look for unexpected JavaScript, module, or asset requests to domains not normally used by the application immediately after visits to pages containing user-generated content. Review CSP violation reports for blocked script-src or worker-src loads from unfamiliar origins, especially where the blocked URI appears after loading Vite bundles. Inspect deployed JavaScript bundles and sourcemaps for document.currentScript and __VITE_ASSET__ patterns to identify potentially exploitable pages. If compromise is suspected, collect the rendered DOM of affected pages, stored user content revisions, CDN request logs, CSP reports, and endpoint/browser security telemetry showing network connections to attacker-controlled script hosts. Because this is client-side XSS, server-side compromise artifacts may be absent; focus on malicious content injection, unexpected outbound script loads by users' browsers, and anomalous authenticated actions following page views.

• __VITE_ASSET__
• document.currentScript
• name="currentScript"
• id="currentScript"
• name='currentScript'
• id='currentScript'
• <img name="currentScript"
• <img id="currentScript"
• <iframe name="currentScript"
• <form name="currentScript"
• Content-Security-Policy-Report-Only
• violated-directive":"script-src
• blocked-uri

What your security team should do

• Inventory applications and packages using Vite, including transitive frontend build pipelines and deployed static assets.
• Prioritize internet-facing applications, applications with user-generated HTML, CMS/rich-text features, comments, profiles, support portals, and admin consoles that display untrusted content.
• Upgrade Vite to the appropriate patched version and force a clean rebuild and redeployment of all affected JavaScript bundles.
• Search source and build configuration for cjs, iife, or umd output formats and dynamic import usage; prioritize these for validation.
• Harden HTML sanitization policies to remove unsafe name, id, and src attributes from user-controlled markup, not just script tags and event handlers.
• Deploy or tighten Content Security Policy to restrict script loading to trusted origins and reduce the impact of DOM-based XSS.
• Perform targeted log and content review for stored HTML payloads attempting DOM clobbering with currentScript-related name or id values.
• Add regression tests that render user-supplied HTML near Vite bundles and verify document.currentScript cannot be clobbered into loading attacker-controlled scripts.