Critical Red Hat Quay Flaw Lets Attackers Read and Overwrite All Private Container Images in a Registry
Red Hat Quay disclosed that a credential was leaked, exposing a trust relationship that could have been abused.

Red Hat Quay disclosed that a credential was leaked, exposing a trust relationship that could have been abused.
A critical flaw in Red Hat Quay allows an attacker who can access a Quay registry to read and overwrite private container images in every repository.
Quay enables anonymous access by default, and while it is enabled, the attacker needs no account.
The company has released fixed builds for eight Quay 3 branches.
A second critical flaw, CVE-2026-110697 (CVSS score: 9.9), was disclosed at the same time.
The logic behind CVE-2026-123710 has been in Quay since its first public commit, according to the bug report for that flaw.
Anyone connected to Red Hat Quay through the compromised trust relationship is potentially affected, not just Red Hat Quay itself.
When it is off, anyone with a valid account can still exploit the flaw, Red Hat said yesterday.
The attacker can also push or overwrite images, and the change propagates to every system that later pulls those images.
There's no patch for a leaked credential the way there is for a code flaw; the only fix is making sure it's actually dead, not just flagged as risky.
Quay uses keys it trusts to sign the access tokens that allow image pushes and pulls.
With those tokens, an attacker can retrieve private images and any secrets or credentials stored within them.
The trust mechanism involved here is an OAuth or access token, which is what let access move between otherwise unrelated systems.
Quay then accepts tokens signed with that key for any repository.
It can also be used to delete the keys that running Quay instances use, so normal pushes and pulls start failing with authentication errors.
Red Hat Quay says the credential has been revoked, and no exploitation has been confirmed so far.
Quay's key server checks that a request to replace a key carries a token signed by a trusted key, with the expected audience and issuer.
It does not check whether the token was issued for key rotation.
If you have any integration or dependency involving Red Hat Quay, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.
Your own credential inventory is worth auditing for keys or tokens with broader access than they actually need -- the same blast-radius problem applies to anything your own organization leaks.
For CVE-2026-123710, its guidance names standalone installs, Quay deployed by the Quay Operator on OpenShift, and the mirror registry for Red Hat OpenShift as affected.
What happened
Red Hat Quay disclosed that a credential was leaked, exposing a trust relationship that could have been abused.
A critical flaw in Red Hat Quay allows an attacker who can access a Quay registry to read and overwrite private container images in every repository.
Quay enables anonymous access by default, and while it is enabled, the attacker needs no account.
What changed
The company has released fixed builds for eight Quay 3 branches.
A second critical flaw, CVE-2026-110697 (CVSS score: 9.9), was disclosed at the same time.
The logic behind CVE-2026-123710 has been in Quay since its first public commit, according to the bug report for that flaw.
Who is affected
Anyone connected to Red Hat Quay through the compromised trust relationship is potentially affected, not just Red Hat Quay itself.
When it is off, anyone with a valid account can still exploit the flaw, Red Hat said yesterday.
The attacker can also push or overwrite images, and the change propagates to every system that later pulls those images.
Why it matters
There's no patch for a leaked credential the way there is for a code flaw; the only fix is making sure it's actually dead, not just flagged as risky.
Quay uses keys it trusts to sign the access tokens that allow image pushes and pulls.
With those tokens, an attacker can retrieve private images and any secrets or credentials stored within them.
Technical details
The trust mechanism involved here is an OAuth or access token, which is what let access move between otherwise unrelated systems.
Quay then accepts tokens signed with that key for any repository.
It can also be used to delete the keys that running Quay instances use, so normal pushes and pulls start failing with authentication errors.
Response
Red Hat Quay says the credential has been revoked, and no exploitation has been confirmed so far.
Quay's key server checks that a request to replace a key carries a token signed by a trusted key, with the expected audience and issuer.
It does not check whether the token was issued for key rotation.
What security teams should do
If you have any integration or dependency involving Red Hat Quay, rotate any credentials shared with it as a precaution, even without confirmation you were directly affected.