Skip to content

crosvm

Bug bounty on Sorona crosvm.dev

Accepting reports open-source
Top reward
$16,000
Top severity paid
High
Assets in scope
8
Public CVEs
2
Last change
No changes yet

At a glance

What to know before you start testing.

Pays up to $16,000
for high bugs, from $625.
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 Reward
High $16,000 from $2,500
Medium $1,250 from $625
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

Top reward over time USD, since 11 Nov 2026
$16,000 11 Nov 2026: $2,500 12 Nov 2026: $16,000 (was $2,500) Nov 2026 Today
Top reward by date
2026-11-11$2,500
2026-11-12$16,000
Earlier reward tables (2)
  • 11 Nov 2026 to 12 Nov 2026: Medium up to $625
  • 11 Nov 2026 to 12 Nov 2026: High up to $2,500

Scope

8 assets you may test, 8 excluded.

Web 1

  • https://crosvm.dev

Products and areas 7

  • The ChromeOS VRP takes any security issue affecting the ChromeOS ecosystem, and crosvm ships in every ChromeOS image as the VMM behind Crostini, ARCVM and Steam. One severity table applies with no per-asset rows, so a single Critical reaches $30,000
  • The control socket and command-line surface used to build and manage a VM, plus the vsock services Crostini and ARCVM expose across the guest boundary
  • The graphics path, covering virtio-gpu, the wayland proxy and the cross-domain route into the host compositor and renderer
  • The plumbing that stands a guest up: kernel and firmware loading, ACPI and device-tree construction, PCI and interrupt emulation, pvclock, and the vhost and vhost-user backends crosvm talks to
  • The sandbox crosvm builds around itself: the process-per-device split, the minijail wrapping and the seccomp policy files shipped for each device type
  • The virtio device models crosvm implements, from block, net and console through gpu, sound, video, input, balloon, vsock, virtiofs, 9p and pmem, wherever guest-controlled data reaches them
  • The VMM core: KVM setup, vCPU threads, guest memory mapping, and the MMIO, port-IO and ioevent dispatch that carries every guest exit into device code
Out of scope (8)
  • Crashes that fall short of a full denial of service: the rules exclude bugs that cause a crash unless restart is not possible
  • crosvm as it ships inside the Android Virtualization Framework rather than inside ChromeOS, since this program's scope statement is written around the ChromeOS ecosystem
  • Fuzzer crashes filed without showing that an attacker can reach and control the path
  • Graphics-virtualization renderer bugs where the attacker only reaches their own guest's data, since the program treats that process as inside the guest boundary
  • Issues that only manifest with the device in Developer mode, which the rules exclude outright
  • LTS-channel-only findings and hardware past its auto-update expiry, both outside the supported configuration the program pays on
  • Reports filed outside bughunters.google.com with a Google Account, which the rules treat as typically not reward-eligible, and researchers in Russia or Belarus, whom sanctions screening bars from payment
  • Unreachable code paths, and highly or substantially mitigated issues, which the rules state will not qualify for a reward

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.

While testing

  • Submit through sorona.xyz first.
  • Reproduce on a Chromebook or ChromeOS Flex device on supported hardware, running the latest Stable, Beta or Developer channel build in verified mode
  • Developer-mode-only issues, LTS-channel-only issues and hardware past its auto-update expiry are out of scope
  • Submit through bughunters.google.com with a Google Account: the chromeos-security mailing list is accepted but submissions through it are typically not reward-eligible
  • Unreachable code paths and highly or substantially mitigated bugs do not qualify for a reward
  • The patch bonus of up to $10,000 on a Critical is paid for the fix, not for the report, so it is separate work from finding the bug
  • Sanctions screening applies, and no rewards are issued to individuals in Russia or Belarus

Not accepted

  • Issues that only manifest with the device in Developer mode
  • LTS-channel-only findings and hardware past its auto-update expiry
  • Crashes that fall short of a full denial of service
  • Graphics-virtualization renderer bugs where the attacker only reaches their own guest's data
  • Unreachable code paths, and highly or substantially mitigated issues
  • Fuzzer crashes filed without showing that an attacker can reach and control the path

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.

Search NVD

Sorona credits this project with 2 CVEs. The individual records appear here after the next sync.

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 sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Critical (single vulnerability; chain bonuses need a full exploit chain) │ $5,000 - $30,000 │ $6,000 - $31,000 High │ $2,000 - $15,000 │ $2,500 - $16,000 Medium │ $500 - $1,000 │ $625 - $1,250 Any severity, at panel discretion │ $250 │ $313 Submit a vulnerability CVE history 0 Last 12 months 2 Lifetime Memory safety 45 % Code execution 25 % Access control 15 % Info disclosure 10 % Latest advisories Loading the feed Overview crosvm is the Rust virtual machine monitor Google built on KVM, and it is the VMM under Crostini (Linux on ChromeOS), ARCVM (Android apps on ChromeOS) and Steam on ChromeOS, as well as the VMM used by the Android Virtualization Framework. That puts it on the large majority of a Chromebook fleet shipping on the order of 30 million units a year, heavily concentrated in US and EU school districts, and on recent Pixel hardware besides. Its 1,270 GitHub stars are one of the most misleading numbers in open source. The boundary crosvm defends is the one ChromeOS's whole trust model rests on: untrusted Linux and Android code runs inside a VM precisely so that a compromise stays there, and a guest-to-host escape through a virtio device model is by construction a ChromeOS vulnerability. Only two CVEs have ever been assigned, because crosvm defects are tracked in the Chromium issue tracker and surface in release notes rather than as advisories: read the near-zero as unindexed, not as absent. Google pays through the ChromeOS VRP: $500 to $1,000 at Medium, $2,000 to $15,000 at High and $5,000 up to $30,000 for a single Critical, with a patch bonus of up to $10,000 on top if you also land the fix. sorona.xyz adds 1.25× on top of whatever Google awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. In scope The ChromeOS VRP takes any security issue affecting the ChromeOS ecosystem, and crosvm ships in every ChromeOS image as the VMM behind Crostini, ARCVM and Steam. One severity table applies with no per-asset rows, so a single Critical reaches $30,000 The virtio device models crosvm implements, from block, net and console through gpu, sound, video, input, balloon, vsock, virtiofs, 9p and pmem, wherever guest-controlled data reaches them The VMM core: KVM setup, vCPU threads, guest memory mapping, and the MMIO, port-IO and ioevent dispatch that carries every guest exit into device code The sandbox crosvm builds around itself: the process-per-device split, the minijail wrapping and the seccomp policy files shipped for each device type The graphics path, covering virtio-gpu, the wayland proxy and the cross-domain route into the host compositor and renderer The plumbing that stands a guest up: kernel and firmware loading, ACPI and device-tree construction, PCI and interrupt emulation, pvclock, and the vhost and vhost-user backends crosvm talks to The control socket and command-line surface used to build and manage a VM, plus the vsock services Crostini and ARCVM expose across the guest boundary Out of scope Issues that only manifest with the device in Developer mode, which the rules exclude outright LTS-channel-only findings and hardware past its auto-update expiry, both outside the supported configuration the program pays on Crashes that fall short of a full denial of service: the rules exclude bugs that cause a crash unless restart is not possible Graphics-virtualization renderer bugs where the attacker only reaches their own guest's data, since the program treats that process as inside the guest boundary Unreachable code paths, and highly or substantially mitigated issues, which the rules state will not qualify for a reward Fuzzer crashes filed without showing that an attacker can reach and control the path crosvm as it ships inside the Android Virtualization Framework rather than inside ChromeOS, since this program's scope statement is written around the ChromeOS ecosystem Reports filed outside bughunters.google.com with a Google Account, which the rules treat as typically not reward-eligible, and researchers in Russia or Belarus, whom sanctions screening bars from payment Most-valued findings A guest-to-host escape out of a virtio device model: memory corruption driven entirely by guest-controlled descriptors or shared buffers. It is the only realistic route to the $30,000 Critical row, and it is the shape 45% of this project's recorded bug distribution takes Escaping the minijail and seccomp confinement around a compromised device process, the second step that turns a device-model bug into host compromise rather than a contained crash Host or cross-guest memory disclosure reaching a guest through shared memory, balloon or graphics buffers, which breaks the isolation guarantee without needing code execution Access-control errors on the interfaces crosvm deliberately exposes across the boundary: vsock, virtiofs and 9p shared directories, pmem devices, anywhere a guest reaches host state it was never meant to address An escape paired with a persistence primitive that survives a reboot, the combination the $100,000 chain bonus and the $500,000 standing award are written for Any of the above demonstrated in verified mode on a supported Chromebook rather than on a developer-mode or self-built image, because that is the configuration the reward gate is written against Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Reproduce on a Chromebook or ChromeOS Flex device on supported hardware, running the latest Stable, Beta or Developer channel build in verified mode Developer-mode-only issues, LTS-channel-only issues and hardware past its auto-update expiry are out of scope Submit through bughunters.google.com with a Google Account: the chromeos-security mailing list is accepted but submissions through it are typically not reward-eligible Unreachable code paths and highly or substantially mitigated bugs do not qualify for a reward The patch bonus of up to $10,000 on a Critical is paid for the fix, not for the report, so it is separate work from finding the bug Sanctions screening applies, and no rewards are issued to individuals in Russia or Belarus Disclosure Coordinated with Google, on Google's clock. Bugs are made public 14 weeks after the fix ships, and there is a documented appeals path through [email protected] . Because the rules exclude anything disclosed to a third party for purposes other than fixing it, file with Google directly first. 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