- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 14
- 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
14 assets you may test, 5 excluded.
Web 1
- https://xcp-ng.org
Products and areas 13
- Backup and export paths, including XVA import and export and the archives they produce and consume
- Networking, including the Open vSwitch integration and the host network configuration applied on top of it
- Pool membership and the trust relationship between pool members, including the pool secret
- Storage in full: the storage manager, the SMAPI drivers and VDI handling across local, NFS, iSCSI and other backends
- The console proxy and any remote display path bridging a client to a guest console
- The control domain and everything shipped inside it, including the patched Xen build XCP-ng distributes
- The guest tools and every path a guest uses to talk to the control domain
- The installer and the host upgrade path
- The update and patching mechanism, including package signature verification
- The XAPI management stack and its XML-RPC and JSON-RPC API, including authentication and the role-based access control model
- The XCP-ng specific patches and packages layered over the upstream Xen and XenServer heritage
- Vates publishes a dedicated security address for XCP-ng and coordinates hypervisor-level issues through the Xen pre-disclosure list it has belonged to since 2018, while also tracking Citrix Hypervisor advisories. The path is documented on the docs site rather than in a security.txt file, and no component of the distribution is carved out
- XCP-ng's side of the interface Xen Orchestra talks to
Out of scope (5)
- Citrix Hypervisor code rather than XCP-ng's distribution and patching of it
- Defects in upstream Xen itself, which belong to the Xen Security Response Team under the XSA process, unless XCP-ng's own patches are the cause
- Guest operating system defects
- Operator configuration such as exposing the management interface to an untrusted network
- Xen Orchestra's own codebase, which is a separate product with separate reporting
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 privately to the address on the policy page , the dedicated address Vates publishes
-
Say which layer you hit: the XAPI control plane, the control domain, the storage manager or the hypervisor.
-
Give the exact XCP-ng release and the patch level.
-
Xen Orchestra is a separate product. If the bug is in Xen Orchestra's own code, it belongs there rather than here
Not accepted
-
Defects in upstream Xen itself, which belong to the Xen Security Response Team under the XSA process, unless XCP-ng's own patches are the cause
-
Citrix Hypervisor code rather than XCP-ng's distribution and patching of it
-
Xen Orchestra's own codebase, which is a separate product with separate reporting
-
Guest operating system defects
-
Operator configuration such as exposing the management interface to an untrusted network
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 Latest advisories Loading the feed Overview XCP-ng is the turnkey Xen-based hypervisor from Vates, and it is the leading open replacement for Citrix Hypervisor, with heavy use across European public-sector estates and managed service providers. It carries a full Xen host in one product: the hypervisor, the control domain, the XAPI management stack and the storage layer, all on hardware running other people's workloads. Vates operates a dedicated security address and has sat on the Xen pre-disclosure list since 2018, so hypervisor findings coordinate through a real process. Neither Vates nor the Xen project pays anything for that work, so sorona.xyz pays you directly on qualified, reproduced findings. In scope Vates publishes a dedicated security address for XCP-ng and coordinates hypervisor-level issues through the Xen pre-disclosure list it has belonged to since 2018, while also tracking Citrix Hypervisor advisories. The path is documented on the docs site rather than in a security.txt file, and no component of the distribution is carved out The XAPI management stack and its XML-RPC and JSON-RPC API, including authentication and the role-based access control model The control domain and everything shipped inside it, including the patched Xen build XCP-ng distributes Storage in full: the storage manager, the SMAPI drivers and VDI handling across local, NFS, iSCSI and other backends The guest tools and every path a guest uses to talk to the control domain The XCP-ng specific patches and packages layered over the upstream Xen and XenServer heritage Pool membership and the trust relationship between pool members, including the pool secret Backup and export paths, including XVA import and export and the archives they produce and consume The console proxy and any remote display path bridging a client to a guest console Networking, including the Open vSwitch integration and the host network configuration applied on top of it The update and patching mechanism, including package signature verification The installer and the host upgrade path XCP-ng's side of the interface Xen Orchestra talks to Out of scope Defects in upstream Xen itself, which belong to the Xen Security Response Team under the XSA process, unless XCP-ng's own patches are the cause Citrix Hypervisor code rather than XCP-ng's distribution and patching of it Xen Orchestra's own codebase, which is a separate product with separate reporting Guest operating system defects Operator configuration such as exposing the management interface to an untrusted network Most-valued findings Guest escape into the control domain, since a compromised dom0 owns every VM on the host and, through the pool, potentially every host beside it XAPI authentication and authorisation defects, particularly a limited role reaching pool-level operations Anything that leaks or permits reuse of the pool secret, which converts one compromised host into the whole pool Storage manager handling of VDI files and metadata, where guest-written disk content is parsed by control-domain code Import and export handling for XVA archives, which are attacker-controlled input in every migration and backup workflow Update and package verification, where an unsigned or substituted package can be installed on a host Anything in the guest tools channel that lets a guest influence a control-domain action Defects introduced by XCP-ng's own patches on top of upstream Xen, since those get far less review than the upstream code they modify 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 dedicated address Vates publishes There is no security.txt on xcp-ng.org or vates.tech; both return 404. The reporting path is documented on the docs site, so do not assume the well-known path is the answer Findings in upstream Xen itself belong to the Xen Security Response Team under the XSA process. Vates has been on the Xen pre-disclosure list since 2018, so it receives those rather than originating them Say which layer you hit: the XAPI control plane, the control domain, the storage manager or the hypervisor. They route differently and one of them routes upstream Vates also tracks Citrix Hypervisor advisories, so note if the defect is inherited from the shared XenServer heritage rather than written by XCP-ng Xen Orchestra is a separate product. If the bug is in Xen Orchestra's own code, it belongs there rather than here Give the exact XCP-ng release and the patch level. This is a distribution, so the version of every component matters more than usual Disclosure Coordinated privately by the Vates security team through the dedicated address, with hypervisor-level issues handled under the Xen Security Response Process and delivered through the Xen pre-disclosure list that Vates joined in 2018. Product-level findings publish through Vates's own advisories alongside a patched release. Expect coordination to run to a release date rather than to a fixed day count, particularly where an upstream XSA embargo sets the schedule. 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