QSB-120: Two CTAP proxy vulnerabilities
https://www.qubes-os.org/news/2026/10/08/qsb-120/

We have published Qubes Security Bulletin (QSB) 120: Two CTAP proxy vulnerabilities (https://github.com/QubesOS/qubes-secpack/blob/4ea6603c1eb68df12868bf4c97d8efefa8d15799/QSBs/qsb-120-2026.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.

Qubes Security Bulletin 120


---===[ Qubes Security Bulletin 120 ]===---

2026-10-08

Two CTAP proxy vulnerabilities

User action
------------

Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.

Background
-----------

The Client to Authenticator Protocol (CTAP) is a standard governing the
interoperation of authentication devices, such as hardware security
keys, with client platforms, such as laptops. Qubes OS has a feature
known as the Qubes CTAP proxy [3] that enables a USB authentication
device to be used in a given qube without exposing that qube to the full
USB stack, similar to the way the USB keyboard and mouse proxies [4]
work in Qubes. There are multiple versions of CTAP, different ways it
can be used, and various related components that can work with it, so
there's a variety of other terms that you might see associated with
CTAP, such as U2F, CTAP1, CTAP2, FIDO2, WebAuthn, and passkeys.

Qubes users can write RPC policies [5] to control the way CTAP requests
forwarded through the CTAP proxy are handled. There are various request
types that are handled by different qrexec services: ctap.ClientPin,
ctap.GetInfo, u2f.Authenticate, and u2f.Register. In addition, users can
limit the u2f.Authenticate service to specific credentials by allowing
only specific qrexec service arguments.

Summary
--------

This QSB describes two CTAP proxy vulnerabilities:

Vulnerability 1: CTAP requests are supposed to match their requested
service types, but the CTAP proxy fails to enforce this.

Vulnerability 2: When RPC policies limit a qube to sending requests with
specific service arguments, the u2f.Authenticate service incorrectly
allows that qube to request multiple assertions (used for
authentication) as long as any of them match the allowed service
argument.

Impact
-------

Vulnerability 1: A qube that is allowed access to any of the
CTAP-related qrexec services can send any request type. For example,
even if the policy allows a qube access only to ctap.GetInfo, that qube
can also send an authentication request. In realistic configurations,
this means that argument-based filtering of access to specific
credentials is ineffective, since a qube can send authentication
requests through one of its other allowed services. This vulnerability
affects all CTAP versions.

Vulnerability 2: A qube that is allowed to have access only to specific
credentials on a forwarded authentication device can use any credentials
for CTAP2 (but not CTAP1) assertion requests, thereby enabling it to use
those credentials for authentication even though it should not be
allowed to do so.

Affected systems
-----------------

Since these vulnerabilities affect only the CTAP proxy, only users who
use the CTAP proxy on a supported Qubes release are affected. Users who
do not use the CTAP proxy are not affected.

In practice, the only systems that are affected are those in which the
RPC policies have been configured to restrict a qube's access to a
subset of the credentials available on an authentication device, since
otherwise the qube already (intentionally) has access to all
credentials on the authentication device.

These vulnerabilities were introduced in qubes-ctap package version
2.0.0. Older versions of the package (previously known as qubes-u2f) are
not affected.

Discussion
-----------