- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 11
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
11 assets you may test, 5 excluded.
Web 1
- https://vite.dev
Products and areas 10
- Configuration loading, environment variable handling and the import.meta.env inlining that decides which values reach the client bundle
- Origin and host validation on the dev server, covering CORS, the HMR WebSocket endpoint and the checks meant to stop a page in the browser talking to a local dev server
- SSR support and the middleware mode Vite exposes to the frameworks that embed it
- The build pipeline: plugin execution, asset handling and anything that puts content into an output bundle
- The dev server in full: request routing, static file serving, the server.fs allow and deny handling, and every path that maps a URL onto a file on disk
- The HMR channel end to end, including what a connected client is able to ask the server to do
- The module transform and import-analysis pipeline, including how a request path resolves to a module and what ends up inlined into the response
- The plugin API and the official plugins published from the Vite repository
- The policy is a single line: open a private vulnerability report on the repository's security tab. It names no exclusions and draws no boundary narrower than Vite itself, so the whole tool is in scope
- The preview server, which serves a production build and is exposed on a network far more deliberately than vite dev ever is
Out of scope (5)
- An operator deliberately binding the dev server to a public interface and calling that the bug. A traversal past server.fs.deny is a Vite defect; publishing the dev server is a configuration decision
- Bugs in a framework built on Vite rather than in Vite. Nuxt, SvelteKit and Astro run their own security processes
- Findings that require a malicious project's own source or configuration, since running an untrusted repository's build is already code execution by design
- Rollup and esbuild defects that Vite only inherits, unless Vite's own use of them is what makes the issue reachable
- Third-party plugins not published from the Vite repository
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy. "We" in these lines means Sorona, not this site.
While testing
-
Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly.
-
Open a private vulnerability report at github.com/vitejs/vite/security . The policy names exactly one channel and private vulnerability reporting is enabled on the repository
-
Say whether the finding needs the dev server reachable beyond localhost, and describe what a realistic exposure looks like.
-
Give the Vite major version and the relevant server.fs configuration, since this bug class is version-sensitive and configuration-sensitive
-
A finding in Nuxt, SvelteKit or Astro belongs to that project even when Vite is underneath it
-
Hold the detail until the advisory is out.
Not accepted
-
Bugs in a framework built on Vite rather than in Vite
-
Third-party plugins not published from the Vite repository
-
Rollup and esbuild defects that Vite only inherits
-
An operator deliberately binding the dev server to a public interface and calling that the bug
-
Findings that require a malicious project's own source or configuration
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability CVE history 36 Last 12 months Path traversal 40 % Access control 30 % Info disclosure 20 % Injection 10 % Latest advisories Loading the feed Overview Vite is the build tool and dev server under most of the modern JavaScript front end. It is the default for Vue, SvelteKit, Astro, Nuxt, React Router and Angular's newer builder, and npm serves tens of millions of downloads of it every week. The productive surface is the dev server, which reads files off a developer's disk and answers HTTP, and which gets exposed to a network far more often than anyone intends. Its published record is a long run of file-serving bypasses: path traversal and server.fs.deny escapes handing out source the project never meant to publish. Vite pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The policy is a single line: open a private vulnerability report on the repository's security tab. It names no exclusions and draws no boundary narrower than Vite itself, so the whole tool is in scope The dev server in full: request routing, static file serving, the server.fs allow and deny handling, and every path that maps a URL onto a file on disk Origin and host validation on the dev server, covering CORS, the HMR WebSocket endpoint and the checks meant to stop a page in the browser talking to a local dev server The HMR channel end to end, including what a connected client is able to ask the server to do The module transform and import-analysis pipeline, including how a request path resolves to a module and what ends up inlined into the response The preview server, which serves a production build and is exposed on a network far more deliberately than vite dev ever is The build pipeline: plugin execution, asset handling and anything that puts content into an output bundle Configuration loading, environment variable handling and the import.meta.env inlining that decides which values reach the client bundle The plugin API and the official plugins published from the Vite repository SSR support and the middleware mode Vite exposes to the frameworks that embed it Out of scope Bugs in a framework built on Vite rather than in Vite. Nuxt, SvelteKit and Astro run their own security processes Third-party plugins not published from the Vite repository Rollup and esbuild defects that Vite only inherits, unless Vite's own use of them is what makes the issue reachable An operator deliberately binding the dev server to a public interface and calling that the bug. A traversal past server.fs.deny is a Vite defect; publishing the dev server is a configuration decision Findings that require a malicious project's own source or configuration, since running an untrusted repository's build is already code execution by design Most-valued findings Anything reading a file outside the served root or past server.fs.deny . This is the densest class in Vite's record and it keeps producing, because there are many ways to encode a path Origin or host validation failures letting a page in a browser reach a dev server on localhost, since the machine running that server is a developer workstation carrying source and credentials WebSocket and HMR handling that accepts a connection or a message it should have rejected Source map, .env and configuration disclosure through the dev or preview server, where the payload is secrets directly Anything putting attacker-controlled content into a built bundle, which reaches every visitor of the deployed site The same bug classes on the preview server rather than the dev server, since preview is exposed on purpose and therefore reachable in production settings Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Open a private vulnerability report at github.com/vitejs/vite/security . The policy names exactly one channel and private vulnerability reporting is enabled on the repository Fixes ship as GitHub Security Advisories, so credit and the CVE come out through GHSA Say whether the finding needs the dev server reachable beyond localhost, and describe what a realistic exposure looks like. The recurring class here depends on that framing Give the Vite major version and the relevant server.fs configuration, since this bug class is version-sensitive and configuration-sensitive A finding in Nuxt, SvelteKit or Astro belongs to that project even when Vite is underneath it There is no reward. The project pays nothing, and the huntr route that once paid for JavaScript ecosystem findings is closing Disclosure Coordinated through GitHub private vulnerability reporting on vitejs/vite and published as a GitHub Security Advisory alongside a patched release. This bug class has a well-worn path through the process, with a substantial run of published advisories behind it, so expect a fix in a patch release rather than a long embargo. Hold the detail until the advisory is out. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability