Xen Security Advisory 529 v2 (CVE-2026-102705) - XAPI: data-dependent compare function used for Pool Secret

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Xen Security Advisory CVE-2026-102705 / XSA-529
version 2

XAPI: data-dependent compare function used for Pool Secret

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

XAPI has a bearer token used to authenticate requests made between hosts in a pool, known as the Pool Secret.

Comparison of this token is performed with a function which has data-dependent timing. An attacker may be able to use this as a timing oracle to infer the value of the Pool Secret.

IMPACT
======

An unauthenticated attacker may be able to infer the value of the Pool Secret, and gain full access to the pool.

VULNERABLE SYSTEMS
==================

Systems running all versions of XAPI are vulnerable.

MITIGATION
==========

There are no mitigations.

RESOLUTION
==========

Applying the appropriate attached patch resolves this issue.

After deploying the fixed XAPI to all pool members, the Pool Secret can be regenerated by running xe pool-secret-rotate.

xsa529.patch XAPI master

$ sha256sum xsa529*
a8a595891a113ce04665d6075c2ce2bf1a38d05b2df50e1509cadeabd0f525f2  xsa529.patch
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators.

But: Distribution of updated software is prohibited (except to other members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team.

(Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy:
http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrzWmgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZHtwIAIfiXHTw5h+h7UjrIWCuZN53ouEUdJE6V6cWCtsX KSNBpwm9puAg4kVrqSDRF5Uvrwjx6uxFbNMml5OVsZsdOE7KChNZMDk9hhk9HYXC yyObt/9gtRIyD84u9CSc66Oa1noIbrx+awMeX5Z8FWVOAMtNJ/Oiz4LQPmk7fNhv dJCtYVIRBmcCS7AZj9W8H1oQuSd7GOgCLNB4/B0FEKMOWKIWBgzHPFOD4MGWAhFf DTNi+mu7IjmtkXLqPda59C5vG/NMZ18caqSWTAkkihUDwlsuJvONY4F6Ifw8M1fe tEniu0Ko+RfdE2EbsZFShdnrWFHvU459oBxhkI+S3PqXODE=
=MQpF
-----END PGP SIGNATURE-----

From: Ming Lu <[email protected]>
Subject: CA-430076: Variable-time comparison of pool_secret

The [String.equal] will take variable time according to how similar the two strings are in comparison. An attacker can have a byte-at-a-time timing oracle on the pool_secret, making practical secret recovery attacks significantly more feasible.

[Eqaf.equal] instead has data-invariant timing if and only if both strings being compared have the same length. In such case, it does not depend on the contents of the strings being compared, so the time taken to reject a guess reveals nothing about how much of it is correct.

When the lengths differ, [Eqaf.equal] returns early, which reveals whether a guess has the same length as the secret. This is not new. And enough entropy in secret has been enforced. So it's not a critical issue.

This is XSA-529 / CVE-2026-102705.

index 8122674acf8e..5c72e0b97526 100644
@@ -14,6 +14,7 @@
   (flags (:standard -w -33))
   (libraries
     astring
+    eqaf
     rpclib.core
     rpclib.json
     rpclib.xml

index b552e46edfd6..712939dde939 100644
@@ -22,7 +22,7 @@ let write_to_file = Xapi_stdext_unix.Unixext.write_string_to_file ~perms:0o600
 
 let write_to_channel c s = output_string c s
 
-let equal = String.equal
+let equal = Eqaf.equal
 
 let length = String.length