A critical vulnerability in the Red Hat Quay container registry, tracked as CVE-2026-123710 and rated CVSS 9.8, lets attackers take over the registry’s token signing and gain read and write access to any repository. SecurityWeek reported the flaw on November 12, a day after fixes were merged into GitHub.
How Attackers Gain Control of Token Signing
The vulnerability affects Quay’s service key server when untrusted clients can reach it. With anonymous access enabled, an unauthenticated attacker can obtain a registry token. The attacker then abuses key rotation to install their own trusted signing key.
Access Granted by the Malicious Key
With that key in place, the attacker gets read and write access to any repository. That access exposes private images and the secrets embedded in them and allows attackers to overwrite images. SecurityWeek describes the possible result as a software supply-chain compromise through poisoned container images.
Persistence Built Into the Attack
The malicious key has no expiry and survives restarts. When rotation runs, it deletes the legitimate instance key, and the attacker’s key can delete replacement keys. Changing passwords or regenerating robot tokens does not invalidate the attacker’s key.
Disabling Anonymous Access Does Not Close the Hole
Turning off anonymous access does not protect a registry. Any valid Quay account can exploit the flaw, according to the report. That widens the set of possible attackers beyond unauthenticated outsiders to anyone holding an ordinary account on the registry.
Fix Status and Disclosure of Quay CVE-2026-123710
Red Hat’s Dave O’Connor found the vulnerability. The source article names no fixed version. It reports that fixes for CVE-2026-123710 and a second flaw, CVE-2026-110697, were merged into GitHub on November 11. Coverage of the issue appeared on November 12.
Guidance Until a Release Is Available
The report advises restricting access to the key-management service, reviewing logs for suspicious key changes and removing unauthorized keys. It also notes that an attacker could reinstall keys until the patch is applied, so removal of a malicious key does not by itself end the exposure.
The combination of a CVSS 9.8 rating, no required authentication in the anonymous-access case and persistence that survives credential resets makes the flaw unusual among registry bugs. Registries sit upstream of deployment pipelines, so an attacker who can overwrite images can affect every system that pulls them.
SecurityWeek is the only source fetched for the report, and the brief does not specify how many deployments are exposed or whether anyone has used the flaw in attacks. Red Hat has not named a release containing the fix in the material reviewed. Operators who rely on Quay’s service key server being reachable by untrusted clients are the group the vulnerability description applies to, since the weakness depends on that reachability.
Sources and the Second Flaw in the Same Fix Set
SecurityWeek is the sole source for this report. It states that the November 11 upstream fixes cover both CVE-2026-123710 and CVE-2026-110697, though the article does not describe the second flaw in detail.
The report’s description of persistence is the most distinctive element. The attacker’s key does not expire, rotation removes the legitimate instance key and the attacker’s key can delete replacement keys. That sequence means a registry owner who rotates keys without first closing the hole can end up with only the attacker’s key in place.
Red Hat has not named a fixed Quay version in the coverage reviewed, and the story’s timeline rests on two dates: the upstream merge on November 11 and the press coverage on November 12.
Red Hat’s Dave O’Connor, who found the flaw, is the only individual credited in the report. The source gives no count of affected installations and no indication that any attacker has used the technique, so the practical reach of the flaw depends on how many Quay deployments expose the service key server to untrusted clients.
