Citrix Xen Virtualization Software
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Citrix Xen product.
RSS Feeds for Citrix Xen security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Citrix Xen products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Citrix Xen Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2026 there have been 39 vulnerabilities in Citrix Xen with an average score of 6.8 out of ten. Last year, in 2025 Citrix Xen had 9 security vulnerabilities published. That is, 30 more vulnerabilities have already been reported in 2026 as compared to last year. Last year, the average CVE base score was greater by 1.07
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 39 | 6.84 |
| 2025 | 9 | 7.91 |
| 2024 | 19 | 5.72 |
| 2023 | 14 | 6.75 |
| 2022 | 57 | 6.53 |
| 2021 | 27 | 6.96 |
| 2020 | 44 | 6.56 |
| 2019 | 25 | 0.00 |
| 2018 | 27 | 7.72 |
It may take a day or so for new Citrix Xen vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Citrix Xen Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-62434 | Jul 28, 2026 |
Xen PoD Guest Reclaimer Causes Memory Management CorruptionA guest started with Populated on Demand enabled (PoD) can attempt to reclaim pages which aren't regular guest RAM. This can cause corruption of memory management state in Xen. |
|
| CVE-2026-62433 | Jul 28, 2026 |
Xen Hypervisor Unchecked Buffer Count in DM_OP leads to stack corruptionParts of the DM_OP handling code assumes the caller has provided the required number of buffers for the given operation without any checking being done. As a result, certain operations might access stack rubble as structures are possibly uninitialized. |
|
| CVE-2026-62432 | Jul 28, 2026 |
XEN Hypervisor Null Pointer Deref via EVTCHNOP_expand_array RaceThe EVTCHNOP_expand_array hypercall checks for whether FIFO event channels are enabled, but without holding the correct lock. It can race with EVTCHNOP_reset, resulting in dereferencing a NULL pointer. |
|
| CVE-2026-62431 | Jul 28, 2026 |
Xen: Div-by-Zero in Viridian STIMER Handler Causing #DE FaultThe logic to handle periodic Viridian STIMERs performs a division with an unchecked user-controlled divisor value, that can be set to zero to cause a #DE fault. |
|
| CVE-2026-62430 | Jul 28, 2026 |
Xen Hypervisor OOB Read via CMOS Index RaceAccesses to the CMOS memory contents are done using an indirect IO port pair. Therefore Xen needs to cache the guest chosen index, and one of the usages of the index didn't take the necessary locking to avoid concurrent changes. As a result, a guest could change the index after it being checked, causing a subsequent out-of-bound read access to the contents of an array. |
|
| CVE-2026-62429 | Jul 28, 2026 |
Xen vNUMA Config Leak During Guest DestructionAccessing the vNUMA configuration data of a guest is still possible when domain destruction has already started. The cleaning up of that configuration information is not synchronized with its retrieval by a device model controlling the guest. |
|
| CVE-2026-62435 | Jul 28, 2026 |
Xen Grant Table V1/V2 Switch CVE-2026-62435: Locked State Assumption[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436. |
|
| CVE-2026-62436 | Jul 28, 2026 |
Xen Grant Table v2v1 downgrade race condition[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] With the introduction of Grant Table v2 came the requirement to be able to switch between versions. Switching from v1 to v2 reduces the number of valid grant references, as a bigger shared entry structure is then needed while the shared table doesn't change size. Switching from v2 back to v1 the status frames, which are separate in v2, go away. Code holding, but intermediately dropping and then re-acquiring the grant table lock, sometimes wrongly assumes that said properties wouldn't change across the window in time where the lock is not being held. The v1 -> v2 issue is CVE-2026-62435. The v2 -> v1 issue is CVE-2026-62436. |
|
| CVE-2026-62428 | Jul 28, 2026 |
Privilege Escalation via Race Condition in Xen Grant-CopyWhen grant-copy operations are processed, the respective grant may or may not already be in use by another operation (a mapping or another copy). For all copy operations the referenced guest frame is looked up. When another operation is already active for the grant (the grant is "pinned"), what is being supplied back to actually carry out permission checks and copy operation may not be consistent: The permission check may be carried out on a page different from the one involved in the copy. |
|
| CVE-2026-62427 | Jul 28, 2026 |
Xen HV Platform-Op Lock Fairness Vulnerability[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. The sysctl issue is CVE-2026-62426. The platform-op issue is CVE-2026-62427. |
|