- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 13
- Public CVEs
- 9
- 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://libvirt.org
Products and areas 12
- Authentication and access control in full, covering UNIX socket permissions, SASL, the TLS transports and the polkit policy layer
- Domain XML parsing and generation across every driver, including the paths that turn XML into a hypervisor command line
- Migration in full: the source and destination handshake, the transport and the state a receiving host accepts
- Secret handling, covering the secret driver and any credential libvirt holds on a guest's behalf
- The language bindings shipped by the project, including libvirt-python
- The libvirtd daemon and the split modular daemons that replaced it, including virtqemud, virtstoraged, virtnetworkd and the rest of the set
- The network and nwfilter drivers, including the firewall rules libvirt generates on the host
- The non-QEMU drivers (LXC, Xen, bhyve and the others), which share the same daemon and the same privilege
- The published security process accepts confidential GitLab work items, where the security team handles triage, CVE allocation and embargo. It declares no component boundary, so the whole management stack is in
- The QEMU driver and the QMP monitor conversation, plus how libvirt sets up the confinement of the QEMU process it launches
- The RPC protocol end to end: the wire format, XDR decoding and every API entry point it dispatches to
- The storage driver set: pools, volumes, disk image handling and anything that probes or rewrites image metadata
Out of scope (5)
- Defects in QEMU, Xen or another hypervisor rather than in libvirt's handling of it
- Deliberate administrator configuration, such as granting an ordinary user access to the read-write system socket
- Distribution packaging and downstream patches
- Issues already published in the libvirt security notice repository
- SELinux or AppArmor policy shipped by a distribution rather than by libvirt
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.
-
Create a confidential work item in the libvirt GitLab project and ensure the confidentiality checkbox is selected
-
Verify the finding by hand and say what produced it
-
Name the daemon: the monolithic libvirtd and the split modular daemons have different privilege and different sockets, and it changes the severity
-
State which socket the attack reaches: the read-only socket, the read-write system socket and the session socket are three different trust levels
-
Include the domain XML that reproduces it. Most of the interesting surface here starts with XML a less privileged caller supplied
-
Historical issues are published in the libvirt-security-notice git repository in text, HTML and XML, so check there before reporting
Not accepted
-
Defects in QEMU, Xen or another hypervisor rather than in libvirt's handling of it
-
SELinux or AppArmor policy shipped by a distribution rather than by libvirt
-
Distribution packaging and downstream patches
-
Deliberate administrator configuration, such as granting an ordinary user access to the read-write system socket
-
Issues already published in the libvirt security notice repository
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.
| CVE | Summary | Severity | Published |
|---|---|---|---|
| CVE-2015-5160 | libvirt before 2.2 includes Ceph credentials on the qemu command line when using RADOS Block Device (aka RBD), which allows local users to obtain sensitive information via a process listing. | Medium 5.5 | 20 Aug 2018 |
| CVE-2014-3633 | The qemuDomainGetBlockIoTune function in qemu/qemu_driver.c in libvirt before 1.2.9, when a disk has been hot-plugged or removed from the live image, allows remote attackers to cause a denial of service (crash) or read sensitive heap information via a crafted blkiotune query, which triggers an out-of-bounds read. | Medium 5.8 | 6 Oct 2014 |
| CVE-2014-3657 | The virDomainListPopulate function in conf/domain_conf.c in libvirt before 1.2.9 does not clean up the lock on the list of domains, which allows remote attackers to cause a denial of service (deadlock) via a NULL value in the second parameter in the virConnectListAllDomains API command. | Medium 5.0 | 6 Oct 2014 |
| CVE-2010-2239 | Red Hat libvirt, possibly 0.6.0 through 0.8.2, creates new images without setting the user-defined backing-store format, which allows guest OS users to read arbitrary files on the host OS via unspecified vectors. | Medium 4.4 | 19 Aug 2010 |
| CVE-2010-2242 | Red Hat libvirt 0.2.0 through 0.8.2 creates iptables rules with improper mappings of privileged source ports, which allows guest OS users to bypass intended access restrictions by leveraging IP address and source-port values, as demonstrated by copying and deleting an NFS directory tree. | Low 2.1 | 19 Aug 2010 |
| CVE-2010-2237 | Red Hat libvirt, possibly 0.6.1 through 0.8.2, looks up disk backing stores without referring to the user-defined main disk format, which might allow guest OS users to read arbitrary files on the host OS, and possibly have unspecified other impact, via unknown vectors. | Medium 4.4 | 19 Aug 2010 |
| CVE-2010-2238 | Red Hat libvirt, possibly 0.7.2 through 0.8.2, recurses into disk-image backing stores without extracting the defined disk backing-store format, which might allow guest OS users to read arbitrary files on the host OS, and possibly have unspecified other impact, via unknown vectors. | Medium 4.4 | 19 Aug 2010 |
| CVE-2009-0036 | Buffer overflow in the proxyReadClientSocket function in proxy/libvirt_proxy.c in libvirt_proxy 0.5.1 might allow local users to gain privileges by sending a portion of the header of a virProxyPacket packet, and then sending the remainder of the packet with crafted values in the header, related to use of uninitialized memory in a validation check. | Medium 4.4 | 11 Feb 2009 |
| CVE-2008-5086 | Multiple methods in libvirt 0.3.2 through 0.5.1 do not check if a connection is read-only, which allows local users to bypass intended access restrictions and perform administrative actions. | High 7.2 | 19 Dec 2008 |
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 libvirt is the management API sitting above the hypervisor, and it is what virsh, virt-manager and OpenStack Nova all speak to. It is installed on essentially every Linux virtualization host, and its daemon has historically run as root while brokering every VM lifecycle operation on the machine, so an authorisation bypass here is fleet-wide rather than one guest. Red Hat stewards a genuinely mature process: a standing security team drawn from core developers and vendor security engineers, a documented embargo policy, CVE allocation and a machine-parsable notice repository. No money is attached to any of it, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The published security process accepts confidential GitLab work items, where the security team handles triage, CVE allocation and embargo. It declares no component boundary, so the whole management stack is in The libvirtd daemon and the split modular daemons that replaced it, including virtqemud, virtstoraged, virtnetworkd and the rest of the set The RPC protocol end to end: the wire format, XDR decoding and every API entry point it dispatches to Authentication and access control in full, covering UNIX socket permissions, SASL, the TLS transports and the polkit policy layer Domain XML parsing and generation across every driver, including the paths that turn XML into a hypervisor command line The QEMU driver and the QMP monitor conversation, plus how libvirt sets up the confinement of the QEMU process it launches The storage driver set: pools, volumes, disk image handling and anything that probes or rewrites image metadata The network and nwfilter drivers, including the firewall rules libvirt generates on the host Secret handling, covering the secret driver and any credential libvirt holds on a guest's behalf Migration in full: the source and destination handshake, the transport and the state a receiving host accepts The non-QEMU drivers (LXC, Xen, bhyve and the others), which share the same daemon and the same privilege The language bindings shipped by the project, including libvirt-python Out of scope Defects in QEMU, Xen or another hypervisor rather than in libvirt's handling of it SELinux or AppArmor policy shipped by a distribution rather than by libvirt Distribution packaging and downstream patches Deliberate administrator configuration, such as granting an ordinary user access to the read-write system socket Issues already published in the libvirt security notice repository Most-valued findings Authorisation bypass where a connection on the read-only socket reaches a mutating API. The daemon runs as root and drives every guest on the host, so the gap between those two sockets is the highest-value boundary in the codebase Path traversal or arbitrary file access through the storage and disk-image paths, since the daemon touches those paths with full privilege Anything that turns guest-controlled or caller-supplied XML into a host command line, a host file write or an unexpected QEMU argument Privilege escalation from a user with limited libvirt access to full control of the virtualization host Defects in the migration handshake, where one host accepts machine state produced by another Memory safety in RPC decoding, reachable by anything that can open a socket the daemon listens on Race conditions in concurrent API handling against the same domain, where two operations interleave into a state neither would produce alone Weaknesses in the confinement libvirt sets up around QEMU, since that confinement is the second line after a device-model escape 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. Create a confidential work item in the libvirt GitLab project and ensure the confidentiality checkbox is selected Triage runs through a standing security team of libvirt core developers plus nominated security engineers from each distributing vendor, so assume distribution security teams see your report early The bug-reporting page now sets explicit expectations around automated tooling and AI agents. Verify the finding by hand and say what produced it Name the daemon: the monolithic libvirtd and the split modular daemons have different privilege and different sockets, and it changes the severity State which socket the attack reaches: the read-only socket, the read-write system socket and the session socket are three different trust levels Include the domain XML that reproduces it. Most of the interesting surface here starts with XML a less privileged caller supplied Historical issues are published in the libvirt-security-notice git repository in text, HTML and XML, so check there before reporting Disclosure Coordinated by the libvirt security team against a documented embargo policy, with a CVE allocated and a branch-fixing policy covering which maintained releases receive the patch. Publication lands as a libvirt security notice in the project's machine-parsable notice repository alongside the fixed releases. Distributions carry the fix in lockstep because their own security engineers sit on the team, so the practical embargo runs to that coordinated release rather than to a fixed day count. 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