distronews.com stable7.3.1
Qubes OS News

QSB-120: Two CTAP proxy vulnerabilities

qubes-os.org

Key points

Qubes Security Bulletin 120, dated 2026-10-08, describes two flaws in the Qubes CTAP proxy, the feature that lets a qube use a USB authentication device (security key) without exposing that qube to the full USB stack. Both weaken the RPC policies that are meant to limit which credentials a qube may use.

The two vulnerabilities

  • Vulnerability 1: the proxy does not check that a CTAP request matches the qrexec service it was sent through. A qube allowed any one of ctap.ClientPin, ctap.GetInfo, u2f.Authenticate or u2f.Register can send every request type; a qube allowed only ctap.GetInfo can still send an authentication request. All CTAP versions are affected.
  • Vulnerability 2: when a policy limits a qube to specific service arguments, u2f.Authenticate lets it request several assertions as long as any one of them matches the allowed argument. The qube can then authenticate with credentials it was not given, for CTAP2 requests but not CTAP1.
  • In realistic configurations the first flaw makes argument-based filtering of credentials ineffective, because the request can go through another allowed service.

Who is affected

  • Only users of the CTAP proxy on a supported Qubes release; users who do not use the proxy are not affected.
  • In practice, only systems whose RPC policies restrict a qube to a subset of the credentials on a device. Without such a restriction the qube already has access to all of them by design.
  • The flaws were introduced in qubes-ctap 2.0.0. Older versions of the package, then called qubes-u2f, are not affected.

What it does and does not allow

  • A malicious website cannot use either flaw unless the browser has a separate exploitable vulnerability, since the browser limits each site to its own authentication requests.
  • What is lost is the second layer: a qube that is already compromised can reach credentials on the device that policy was supposed to withhold.
  • The RPC policies are enforced correctly, so this is not a qrexec vulnerability; the fault is in how the CTAP proxy implements its qrexec services.

Patching

  • Qubes 4.3: qubes-ctap 2.0.8, installed in the template of the USB qube(s).
  • The package moves from the security-testing repository to the current (stable) repository over the next two weeks, after community testing.
  • Install it through the Qubes Update tool or its command-line equivalents; updating normally is the only action required.
  • The fix takes effect only after the templates have been updated and shut down and every USB qube has been restarted.

Credits

  • Vulnerability 2 was reported by Giulio Berra of the Freedom of the Press Foundation.
  • Vulnerability 1 was found internally by Piotr Bartman-Szwarc while reviewing that report.

Summary by DistroNews, based on the original post.

We have published Qubes Security Bulletin (QSB) 120: Two CTAP proxy vulnerabilities. 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.

This is the opening of the story. The full text is on the original page.

Read the original at qubes-os.org