Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

Cloud Hypervisor

Bug bounty on Sorona cloudhypervisor.org

Accepting reports open-source
Go to program Website
Top reward
$1,500
Top severity paid
Critical
Assets in scope
13
Public CVEs
3
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 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

13 assets you may test, 5 excluded.

Web 1

  • https://www.cloudhypervisor.org

Products and areas 12

  • ACPI tables, firmware loading and the PCI configuration space presented to the guest
  • Device hotplug and VFIO passthrough handling
  • Disk image handling for QCOW, VHDX and raw formats, including backing-file resolution and every field parsed out of an image header
  • Guest memory management, the KVM and MSHV hypervisor abstraction layers, and the shared memory regions between them
  • The HTTP API and its socket, plus the D-Bus API, covering every action a control plane can request
  • The migration path, including the state a destination instance accepts from a source it does not control
  • The seccomp filter set confining each Cloud Hypervisor worker thread
  • The security policy accepts reports through GitHub Security Advisories and points at a published threat model that defines what counts as a vulnerability, including a presumption that memory corruption is exploitable until proven otherwise. No component of the VMM is carved out
  • The virtio device model in full: block, net, balloon, vsock, fs, iommu, rng and console, along with the transports beneath them
  • vhost-user backends as Cloud Hypervisor drives them, including the socket protocol between the two sides
  • virtio-fs and virtio-vsock, the two paths that bridge host resources into a guest by design
  • VM lifecycle operations: boot, pause, resume, snapshot, restore and live migration
Out of scope (5)
  • Defects in KVM, MSHV or the host kernel rather than in Cloud Hypervisor's use of them
  • Denial of service that depends on an operator deliberately removing resource limits
  • Guest kernel and guest firmware defects
  • Issues already covered by a published advisory or under an active embargo
  • rust-vmm crates consumed as dependencies, unless the integration in this repository is what makes the bug reachable

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.
  • Report through GitHub Security Advisories on cloud-hypervisor/cloud-hypervisor, the intake the policy names
  • Read docs/threat-model.md first. It defines what the project counts as a vulnerability, and it is the document your report will be triaged against
  • A reproducible crash is enough. The policy presumes any known or potential memory corruption is exploitable until proven otherwise, so you do not need a weaponised exploit to qualify
  • Expect a fourteen-day embargo with the GHSA number announced publicly while the content stays private
  • The embargo partner list is published and includes Microsoft, Meta, Google, Crusoe, Cyberus Technology and UbiCloud, so assume those vendors have the detail before the public does
  • Say which hypervisor layer you ran on. The KVM and MSHV backends are different code paths and the severity can differ between them

Not accepted

  • Defects in KVM, MSHV or the host kernel rather than in Cloud Hypervisor's use of them
  • rust-vmm crates consumed as dependencies, unless the integration in this repository is what makes the bug reachable
  • Guest kernel and guest firmware defects
  • Denial of service that depends on an operator deliberately removing resource limits
  • Issues already covered by a published advisory or under an active embargo

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
CVESeverityPublished
CVE-2026-27211 Critical 9.1 21 Feb 2026
CVE-2023-30612 Medium 4.0 19 Apr 2023

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 2 Last 12 months 3 Lifetime Memory safety 45 % Host file disclosure/write 25 % Image parsing 20 % Sandbox/seccomp 10 % Latest advisories Loading the feed Overview Cloud Hypervisor is a Rust VMM built on the rust-vmm crates and aimed at general-purpose cloud workloads rather than short-lived functions. Azure Boost, Crusoe Cloud and UbiCloud run on it, and it is an increasingly common Kata Containers backend. Both advisories from the last twelve months crossed the guest-to-host line: CVE-2026-45782, a use-after-free in virtio-block async I/O completion, and CVE-2026-27211, host file exfiltration through QCOW backing-file abuse. The security policy states outright that there is no bug bounty programme, while the published embargo list runs to Microsoft, Meta and Google. sorona.xyz pays you directly on qualified, reproduced findings. In scope The security policy accepts reports through GitHub Security Advisories and points at a published threat model that defines what counts as a vulnerability, including a presumption that memory corruption is exploitable until proven otherwise. No component of the VMM is carved out The virtio device model in full: block, net, balloon, vsock, fs, iommu, rng and console, along with the transports beneath them Disk image handling for QCOW, VHDX and raw formats, including backing-file resolution and every field parsed out of an image header Guest memory management, the KVM and MSHV hypervisor abstraction layers, and the shared memory regions between them The HTTP API and its socket, plus the D-Bus API, covering every action a control plane can request VM lifecycle operations: boot, pause, resume, snapshot, restore and live migration The migration path, including the state a destination instance accepts from a source it does not control Device hotplug and VFIO passthrough handling The seccomp filter set confining each Cloud Hypervisor worker thread vhost-user backends as Cloud Hypervisor drives them, including the socket protocol between the two sides virtio-fs and virtio-vsock, the two paths that bridge host resources into a guest by design ACPI tables, firmware loading and the PCI configuration space presented to the guest Out of scope Defects in KVM, MSHV or the host kernel rather than in Cloud Hypervisor's use of them rust-vmm crates consumed as dependencies, unless the integration in this repository is what makes the bug reachable Guest kernel and guest firmware defects Denial of service that depends on an operator deliberately removing resource limits Issues already covered by a published advisory or under an active embargo Most-valued findings Guest-to-host memory corruption in the virtio path. CVE-2026-45782 was a use-after-free in virtio-block async I/O completion, and the policy treats memory corruption as exploitable by default, so this class needs no exploit chain to be taken seriously Host file access driven from guest-supplied or image-supplied data. CVE-2026-27211 exfiltrated host files through QCOW backing-file handling Disk image parsing generally, since a QCOW file is attacker-controlled input in any workflow that accepts a customer image Snapshot, restore and live migration state handling, where a receiving VMM parses structures it did not produce API socket authorisation, particularly actions reachable before or during boot Seccomp filter gaps that widen what a compromised worker thread can call on the host virtio-fs and vsock paths, which carry host resources into a guest by design and have the shortest route to host state 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. Report through GitHub Security Advisories on cloud-hypervisor/cloud-hypervisor, the intake the policy names Read docs/threat-model.md first. It defines what the project counts as a vulnerability, and it is the document your report will be triaged against A reproducible crash is enough. The policy presumes any known or potential memory corruption is exploitable until proven otherwise, so you do not need a weaponised exploit to qualify Automated discovery is explicitly welcomed, including large language models. Name the tool you used and apply a good-faith false-positive filter, which the policy asks for while saying a zero false-positive rate is not worth chasing Expect a fourteen-day embargo with the GHSA number announced publicly while the content stays private The embargo partner list is published and includes Microsoft, Meta, Google, Crusoe, Cyberus Technology and UbiCloud, so assume those vendors have the detail before the public does Say which hypervisor layer you ran on. The KVM and MSHV backends are different code paths and the severity can differ between them Disclosure Coordinated through the GitHub Security Advisory workflow with a fourteen-day embargo, during which the GHSA number is announced publicly while the content stays private and a named partner list of downstream vendors receives the detail. The criteria for joining that list are published, which makes the process unusually legible from the outside. Publication lands as the advisory plus a patched release, so hold detail until both are 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