- Red Hat says CVE-2026-123710 affects Quay deployments where untrusted clients can reach /keys. There, an unauthenticated client can install its own signing key and gain read and write access to any repository.
- Red Hat says deleting a rogue key does not hold until a fixed build is deployed. SecurityWeek says no fixed version is named yet.
- Restrict the /keys endpoint to trusted internal components, and check audit logs for key changes with no expiry date.
The registry decides what your systems trust
A container registry is where a company keeps the packaged software it runs in production. Whoever controls what the registry serves controls what gets deployed. So the most valuable thing in a registry is not an image. It is the key that proves who may touch the images.
Red Hat disclosed CVE-2026-123710 in its Quay registry. Red Hat says it affects deployments where untrusted clients can reach the /keys endpoint. In those deployments, an unauthenticated attacker can take over the signing of registry tokens. SecurityWeek gives the flaw a CVSS score of 9.8. Red Hat calls its own score preliminary.
How the attack works
Quay uses signed tokens, called JWTs, to decide who may read or write each repository. A service key server holds the approved keys that sign those tokens. Keys can be rotated, which means swapped for new ones.
Red Hat's advisory says the rotation step verifies the token's signer, audience and issuer, but not that it is a rotation credential.
That gap lets in a token from the registry's /v2/auth endpoint, which anyone can request anonymously. Red Hat says an unauthenticated client can get one whose audience the client chooses.
The client hands that token to the rotation endpoint. In return, the attacker's own key becomes an approved signing key. Red Hat says that key can be set to never expire.
Now the attacker can sign tokens. Red Hat says the registry accepts them for any repository. The attacker can read private images and swap out the images behind repository tags.
Red Hat files the weakness as CWE-1287, improper validation of the specified type of input. In plain terms, the system asked only whether a token was genuine. It never asked whether it was the right kind.
Turning off anonymous access is not enough
SecurityWeek says that with anonymous access on, an attacker needs no account. Red Hat's guidance, as the outlet quotes it, is that switching anonymous access off does not protect you. Any valid Quay account can still use the flaw.
SecurityWeek adds that the rogue key can have no expiry date. It survives registry restarts unless someone removes it.
It also quotes Red Hat's Bugzilla report on a side effect. Rotation removes the real instance key. The attacker's key can then delete any replacement keys.
SecurityWeek says this could stop legitimate users from uploading or downloading images.
The outlet also reports that a password change or a new robot token does not cancel a rogue signing key. The usual reply to suspected misuse misses this problem.
The condition matters. Red Hat says only deployments where untrusted clients can reach /keys are affected. Where that endpoint is closed to them, this route is not open.
What is at stake: whether you can trust your images
The first risk is exposure. SecurityWeek notes that private images can hold credentials and other secrets. The second is tampering. The outlet says attackers could overwrite images that other systems later download.
Picture the platform engineer who must answer one question after an incident. Which of our images is the one we built? With a hostile key in play, memory is not enough. That answer needs evidence. The log review Red Hat describes is a place to start.
Think of a building with good locks and an open door to the locksmith's shop. The locks were fine. The place that makes keys was not.
What to do now
Red Hat's first step is to limit who can reach /keys. Do it at the proxy or load balancer. Only trusted internal components should get through.
Its second step is a log review. Search the audit trail for key rotations and key deletions that left the expiration field empty. Then remove any approved service key you do not recognise.
Red Hat adds a warning. Removing a rogue key will not hold until you run a fixed build. The anonymous request can simply install another key.
SecurityWeek says no fixed version appears in the advisory or the Bugzilla report. It reports that fixes for this flaw and for CVE-2026-110697 were merged into the project's GitHub repository on November 11.
Questions to put to your platform team this week:
Can anything other than trusted internal components reach /keys? Who reviewed the proxy rules, and when? Do audit logs show a key rotation with no expiry date that nobody can explain? If a rogue key were installed, how would we prove which images are ours?
The lesson is that access control is only as strong as the process that issues the keys. Check that process first.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Red Hat.
