Red Hat Quay flaw lets attackers forge registry tokens

Red Hat has disclosed CVE-2026-123710, a critical flaw in the Quay container registry that lets an unauthenticated attacker take over the registry's token signing. Red Hat scores it 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, marked preliminary) in its advisory. The fix was merged into Project Quay on 11 November in PR #8057, alongside a second flaw, CVE-2026-110697. The issue was reported by Red Hat's Dave O'Connor.

What the bug does

Quay signs the short-lived tokens it hands out for registry operations. Per Red Hat's description, an attacker first obtains an anonymous registry token, then uses it to install their own signing key through the key-management service — a key they can give no expiration. From there they forge registry tokens that Quay accepts for any repository, giving read and write access to private images and the ability to overwrite the tags other systems pull.

Three properties make it worse than a normal auth bug:

• Persistence. The rogue key survives registry restarts and is not invalidated by changing passwords or regenerating robot tokens.
• Supply-chain reach. Overwriting a tag means every downstream system that pulls that image pulls the attacker's.
• Self-inflicted outage. Key rotation can delete the legitimate instance key, breaking legitimate pushes and pulls.

What's affected

The advisory does not name specific Quay versions. The exposure is any deployment where the key-management endpoint (/keys) is reachable by untrusted clients. Disabling anonymous access does not close the hole on its own — Red Hat notes any valid Quay account can still exploit it. No fixed build is named in the advisory yet; the fix is in the merged pull request.

Red Hat has not stated whether the flaw has been exploited in the wild.

Action checklist

1. Restrict /keys at the edge. Red Hat's interim mitigation is to block or restrict access to the key-management endpoint at the reverse proxy or load balancer so untrusted clients can't reach it.

2. Hunt for rogue keys now. Review Quay audit logs for key operations with no expiry. Red Hat points specifically at these events:

   Review audit logs for service_key_rotate and service_key_delete events with a null expiration_date.

3. Remove any unauthorized signing keys you find, but note a rogue key is not durably gone until a fixed build is deployed.

4. Deploy the fix once a patched release is available; track PR #8057 and the Bugzilla report for the build number.

5. Treat pulled images as suspect if /keys was internet-reachable — the integrity impact means a tag you trusted could have been overwritten.

Context

A registry that signs its own tokens is a single point of trust for every image it serves, which is why a pre-auth signing-key takeover scores 9.8 on confidentiality and integrity: the attacker doesn't just read private images, they can poison what your clusters deploy. It lands in a run of supply-chain-adjacent registry and CI compromises this month — the same week a stolen-token campaign planted CI secret-stealers across tens of thousands of GitHub repositories. The common thread: the build and distribution plane is now the target, and the mitigations that matter are network reachability and audit-log review, not end-user credentials.