Xen Project Hypervisor
By Xen Project Bug bounty on Sorona xenproject.org
- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- 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
13 assets you may test, 5 excluded.
Web 1
- https://xenproject.org
Products and areas 12
- Architecture-specific code for both x86 and Arm, including the Arm SMMU and interrupt controller paths
- Device passthrough: the IOMMU code, PCI passthrough, MSI handling and interrupt remapping
- Grant tables and event channels, the two shared interfaces every guest is designed to touch
- HVM handling in full, including the x86 instruction emulator, viridian enlightenments and nested virtualisation
- Memory management across p2m and m2p tables, shadow and hardware-assisted paging, and page reference counting
- PV and PVH guest handling, including the PV shim used to run PV guests under an HVM container
- The boot path and dom0 construction, plus the hypervisor's own build-time configuration options
- The console, debugging and tracing interfaces reachable from a guest or from dom0
- The hypervisor core: domain lifecycle, scheduling, and the hypercall interface together with the argument validation applied on every call
- The toolstack, covering xl and libxl, libxc and the interface Xen presents to a device model process
- The Xen Security Problem Response Process accepts security problems in Xen Project software reported to the security team address, and carves out no component of the hypervisor. Everything below sits inside that
- xenstore in full, including its transaction handling and the permission model over its nodes
Out of scope (5)
- Configuration that deliberately removes isolation, for example assigning a device without an IOMMU behind it
- Defects in QEMU's device model, which the QEMU project handles under its own process, unless Xen's own use of it is what exposes the flaw
- Downstream distributions of Xen such as XCP-ng or Citrix Hypervisor where the defect sits in the distributor's own code
- Guest kernel or dom0 kernel defects, which belong to the relevant kernel's security process
- Issues already covered by a published XSA
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Report privately to the address on the policy page , the address the Security Problem Response Process names
-
The Security Response Team negotiates the embargo date with you rather than imposing one, so come with a position on timing
-
Discoverers are credited at pre-release unless they opt out; say up front which you want
-
State the guest type (PV, PVH or HVM), the architecture and whether the setup used passthrough.
-
Submit through sorona.xyz.
Not accepted
-
Defects in QEMU's device model
-
Guest kernel or dom0 kernel defects
-
Downstream distributions of Xen such as XCP-ng or Citrix Hypervisor where the defect sits in the distributor's own code
-
Configuration that deliberately removes isolation, for example assigning a device without an IOMMU behind it
-
Issues already covered by a published XSA
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 37 Last 12 months Guest-to-host escape 40 % Privilege escalation 25 % Memory safety 20 % Host denial of service 15 % Latest advisories Loading the feed Overview Xen is a type-1 hypervisor running directly on the hardware, carrying Citrix Hypervisor, XCP-ng and Qubes OS, plus a long-lived pre-Nitro slice of EC2 and a growing safety-certified automotive footprint. An escape here takes the host and every co-tenant on it. The advisory stream makes the case on its own: 37 Xen Security Advisories in the last twelve months, ten of them published on a single day in July 2026, handled through what is widely treated as the best-run disclosure process in open source. None of that researcher labour is paid. The Linux Foundation stewards the project and offers no bounty, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The Xen Security Problem Response Process accepts security problems in Xen Project software reported to the security team address, and carves out no component of the hypervisor. Everything below sits inside that The hypervisor core: domain lifecycle, scheduling, and the hypercall interface together with the argument validation applied on every call Memory management across p2m and m2p tables, shadow and hardware-assisted paging, and page reference counting Grant tables and event channels, the two shared interfaces every guest is designed to touch HVM handling in full, including the x86 instruction emulator, viridian enlightenments and nested virtualisation PV and PVH guest handling, including the PV shim used to run PV guests under an HVM container Device passthrough: the IOMMU code, PCI passthrough, MSI handling and interrupt remapping The toolstack, covering xl and libxl, libxc and the interface Xen presents to a device model process xenstore in full, including its transaction handling and the permission model over its nodes Architecture-specific code for both x86 and Arm, including the Arm SMMU and interrupt controller paths The boot path and dom0 construction, plus the hypervisor's own build-time configuration options The console, debugging and tracing interfaces reachable from a guest or from dom0 Out of scope Defects in QEMU's device model, which the QEMU project handles under its own process, unless Xen's own use of it is what exposes the flaw Guest kernel or dom0 kernel defects, which belong to the relevant kernel's security process Downstream distributions of Xen such as XCP-ng or Citrix Hypervisor where the defect sits in the distributor's own code Configuration that deliberately removes isolation, for example assigning a device without an IOMMU behind it Issues already covered by a published XSA Most-valued findings Guest-to-host escape above everything else. A compromised hypervisor takes every co-tenant on the machine, and this is the class that has historically forced fleet-wide reboots at cloud scale Privilege escalation from an unprivileged guest into dom0 or into a neighbouring domain Hypercall argument validation, wherever a guest-supplied pointer, length or handle is acted on before it is checked Grant table and event channel handling, since those interfaces are reachable by every guest by design and carry references to real host memory Instruction emulation defects in the HVM path, where the hypervisor interprets guest instructions on the guest's behalf IOMMU and passthrough handling, where a guest holding a real device can reach memory it was never assigned Host denial of service a single guest can trigger, which this process does treat as advisory-worthy on shared infrastructure Anything on the Arm side, which sees far less attention than x86 while carrying a growing certified automotive and embedded fleet 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 privately to [email protected] , the address the Security Problem Response Process names The Security Response Team negotiates the embargo date with you rather than imposing one, so come with a position on timing The team proactively notifies other hypervisor projects when a flaw is likely to be shared, so expect your finding to travel further than Xen if the root cause is generic Advisories and patches go to the public Xen security pre-disclosure list before public release. Membership of that list is published with join dates, so assume large downstream vendors see the detail during embargo Discoverers are credited at pre-release unless they opt out; say up front which you want State the guest type (PV, PVH or HVM), the architecture and whether the setup used passthrough. Xen triages very differently across those axes Disclosure Coordinated by the Xen Security Response Team, which allocates the CVE, agrees the embargo date with the discoverer and pre-releases the advisory and patches to the public pre-disclosure list before the XSA goes public on xenbits.xen.org. The stream is high volume and batched, with ten advisories landing on a single day in July 2026, so plan for publication to align with a batch rather than with a fixed day count from your report. 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