If you run Citrix XenServer, Citrix Hypervisor, or XCP-ng in any version, you are affected. The vulnerabilities are in XAPI, the management stack shared by all these products. Every version ever released is affected.
All versions. The vulnerable code has been present since XAPI was first written (~2006). There is no safe version to downgrade to.
Immediate triage across the critical paths:
vm-admin delegated access. Audit VBD.other_config for backend-local keys. Monitor XAPI logs for "Using local override for VBD backend."VDI.sm_config and SR.sm_config for unexpected keys (vhd-parent, paused, activating). Compare on-disk VHD parent chains against database values on NFS/EXT SRs.VM.other_config for is_system_domain=true on non-infrastructure VMs.PBD.device_config records. Verify target/server values match known storage infrastructure IPs. Restrict pool-operator role grants.For all findings: restrict XAPI API access to trusted networks. Deploy the IDS detection rules. The full per-finding remediation guidance is in each advisory at cna.moksha.dk.
19 upstream patch proposals exist. The researcher is retaining them privately under embargo; they are not part of the public disclosure at this time. The advisories at cna.moksha.dk describe each vulnerability in sufficient detail for a competent XAPI engineer to implement their own fix. The total remediation is approximately 200 lines of OCaml. See architectural root causes for the scope.
The researcher has no evidence of wild exploitation and makes no claim either way. The attack surface - input validation on writable API fields - is the most trivially-audited class of vulnerability in software. The XAPI source has been open since 2013. The researcher's position is that it is statistically implausible that well-resourced threat actors have not found some subset of these 89 patterns independently.
No. CitrixBleed (CVE-2023-4966) and CitrixBleed 2 (CVE-2025-5777) are memory-safety vulnerabilities in NetScaler ADC/Gateway. The 89 findings here are input-validation vulnerabilities in XAPI (XenServer's management stack). Different product, different vulnerability class, different attack surface. The only connection is the vendor.
Yes. 74 detection rules (prose spec + Sigma YAML) are available to anyone in the blast radius. Email jakob@wolffhechel.dk with a one-line description of your operational position. No NDA required.
PoC scripts and evidence logs are CSIRT-scoped. Available to national/sectoral CSIRTs and accredited incident responders. Contact via email or Signal (+45 3170 7337) with your CSIRT affiliation.
The 89 advisories at cna.moksha.dk are public. Redistribute freely. The IDS detection rules are provided for operational use - redistribute to parties in your constituency who need them. Attribution to Moksha appreciated but not required.
CVE reservations were submitted to MITRE on 2026-04-09, fifteen days before publication. No response. Parallel filings to GCVE/CIRCL, ENISA, and DIVD also received no response. The researcher self-issued MOKSHA-2026-NNNN identifiers rather than wait. Moksha was approved as GCVE Numbering Authority #117 on 2026-04-28.
MOKSHA-YYYY-NNNN is a self-allocated vulnerability identifier scheme operated by Moksha. It follows the CVE JSON 5.1 schema for tooling compatibility. MOKSHA IDs supplement, not replace, CVE IDs. When MITRE or another CNA assigns CVE IDs, the advisories will be updated with cross-references.
XenServer is excluded from Citrix's bug bounty. Citrix is their own CNA (controls severity assignment). The CVE pipeline was backlogged (15 days, no response). The full rationale documents 10 factors with public source references.
No. This is a public Day-0 disclosure. CERT/CC was notified one day before release. Vates (XCP-ng) received a conditional patch offer on 2026-04-23 with no response before publication. Citrix was not contacted pre-release. The rationale page explains why.
None pre-release. Post-release, Citrix has access to the same public advisories as everyone else at cna.moksha.dk and the disclosure page at shittrix.moksha.dk.
Jakob Wolffhechel, operating as Moksha, a single-person consultancy in Copenhagen, Denmark. Independent security researcher. No vendor affiliation. No competing commercial interests.
Email: jakob@wolffhechel.dk
Signal (preferred for sensitive material): +45 3170 7337