CVE-2024-45811

Vite is a JavaScript tool that can also act like a small web server during development or builds. This bug means the server may accidentally send back “hidden” files it normally would not allow to be read. The attacker’s trick is to craft a link so that when someone opens it, the blocked file contents can be shown in that person’s browser.

This matters if you use vite as a frontend server/tooling component that can serve files to users (for example, a dev server or a setup that exposes the Vite file-serving behavior). If you only use Vite locally with no users reaching it, exposure is much less likely.

The risk is present when the affected Vite version is reachable in practice from a victim’s browser (so the victim must be able to load the crafted Vite URL), and the victim must click/open a link that includes the specific ?import&raw query parameters.

This is RED because this vulnerability has sustained press attention with reported exploitation attempts/claims, meaning attackers are actively interested in using it. Even though it requires tricking a user to open a specific link, the outcome is serious: blocked local files can be returned to the browser.

Confirm exposure

• Identify the Vite version(s) running in this business:
  • Check package.json for vite and confirm the resolved version (and whether multiple apps/packages use different Vite versions).
  • Run npm ls vite (or yarn why vite) to confirm the installed version actually used.
• Determine whether Vite is reachable by other people’s browsers:
  • If your Vite dev server or any Vite server endpoint is accessible from outside your local network (or from customer/staff browsers), treat this as relevant.

Apply the fix

• Upgrade vite to the fixed version(s):
  • Main fixed reference: upgrade to vite 5.4.6.
  • If you are on an older release line, upgrade to the corresponding fixed version: 5.3.6, 5.2.14, 4.5.4, or 3.2.11.
• Rebuild/restart your Vite server after upgrading so the running code matches the updated dependency.

Verify

• After upgrading, validate that attempting the blocked-file access flow using a URL with ?import&raw no longer returns restricted filesystem contents.
• Confirm that normal application behavior still works after the upgrade.

Workarounds if upgrading is delayed

• The findings indicate there are no known workarounds. In practice, the only mitigation you can control quickly is reducing exposure by ensuring the Vite server/file-serving endpoints are not reachable from users’ browsers.

What to monitor

• Check web server/proxy logs for unusual query strings containing import&raw hitting the Vite server routes.
• Review any alerts for unexpected file content responses or abnormal 2xx responses for routes that should not serve local file content.

Severity is RED (per the system verdict), with a medium CVSS score reported in the alert. The flaw is a server filesystem access restriction bypass: @fs is intended to deny access to files outside Vite’s serving allow list, but adding ?import&raw to the URL can bypass that deny logic and return restricted local file contents to the requester.

Attack prerequisites from the findings: no special privileges are required, but user interaction is required (the victim must open/click a crafted link). Exploit reliability is suggested by sustained press attention; KEV listing is not present and there is no public exploit code identified in the findings. No public dated exploitation claim was found in the provided news set, but exploitation interest is still treated as active due to the RED verdict.

Fix maturity: patched releases are available; the findings list vite fixed in 5.4.6 (and also fixed in 5.3.6, 5.2.14, 4.5.5/4.5.4 line per patch cards, and 3.2.11).