Skip to main content
VulnerabilityPublished

CVE-2026-123710: Red Hat Quay 3 · Improper Validation of Specified Type of Input

Affects Red Hat Quay 3Source CVE Database V5

0
Compare

Not known to be exploited · CVSS 9.8 Critical.

Data as of 11 Nov 2026, 15:05 UTC

CVSS 3.1 base score
9.8Critical
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (redhat)CVSS 3.19.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 11 Nov 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 11 Nov 2026.

What to do

Affected software

ProductAffectedFixed in
Red Hat Quay 3quay/quay-rhel8Affected–Fixed in–
Red Hat Quay 3quay/quay-rhel9Affected–Fixed in–
Red Hat Quay 5quay/quay-rhel9Affected–Fixed in–

AI-suggested

Restrict access to the /keys endpoint at the proxy or load balancer level so that only trusted internal components can reach it. Review audit logs for service_key_rotate and service_key_delete events with null expiration_date and remove any unrecognized approved service keys. Note that deleting rogue keys is not a durable fix until a patched version is deployed, as the anonymous request can reinstall keys. Monitor Red Hat's advisory for the release of an official fix and apply it once available.

Description

CVE-2026-123710 is a critical vulnerability in Red Hat Quay 3 that allows an unauthenticated attacker to take over the registry token signing process. By obtaining an anonymous registry token with a controlled audience, the attacker can use the service key rotation endpoint to install their own signing key without expiry. This key can then be used to sign tokens that grant read and write access to any repository, including private images and tag replacements. The vulnerability arises because the key rotation endpoint authenticates callers only by verifying the JWT signature from an approved key and expected audience, without ensuring the token is a valid rotation credential. Deployments exposing the /keys endpoint to untrusted clients are vulnerable.

References

Community reviews

Loading reviews…