If your company keeps private Docker images in a self-hosted registry, stop and check whether it is Red Hat Quay. A newly disclosed Red Hat Quay vulnerability lets an attacker read and overwrite images in every repository, even with anonymous access switched off. The damage does not end at the registry: an overwritten image spreads to every server that pulls it.

According to The Hacker News (published 12 November 2026), Red Hat has released fixed builds for eight Quay 3 branches. Here is what is known and what your engineering team should verify.

A trusted signing key that the attacker adds themselves

The flaw is tracked as CVE-2026-123710 with a CVSS score of 9.8. Quay relies on a set of trusted keys to sign the tokens that authorise image pushes and pulls. An attacker can add their own key to that set, with no expiry date, and then mint valid tokens for any repository.

The root cause is in the key server. It checks that a token was signed by a trusted key, with the expected audience and issuer, but not that the token was issued for key rotation. An anonymous token from the /v2/auth endpoint passes, and the caller chooses its audience.

Because the planted key survives restarts, password resets and robot token changes, surface-level cleanup is not enough. The attacker can also delete the keys running instances depend on, so every push and pull starts failing with authentication errors.

An overwritten image is a way into your whole system

There are two separate risks. The first is data exposure: private images often contain config files, API keys or credentials left in a layer. The second is the supply chain: a swapped image is pulled by CI/CD pipelines and deployment servers, carrying malware with it.

Red Hat stresses that turning off anonymous access does not protect you; with it off, any valid account can still exploit the flaw. Any Quay instance reachable by untrusted clients is at risk, internal registries included.

A second flaw: stealing robot tokens across tenants

Disclosed at the same time, CVE-2026-110697 (CVSS 9.9) lives in the code that lists robot accounts. It builds an SQL LIKE pattern from the namespace name without escaping wildcard characters. In LIKE, an underscore matches any single character, so a namespace with an underscore in the right place can match another tenant's namespace and return its robot accounts with decrypted tokens.

The attacker only needs the right to create a namespace. Where Quay is the integrated registry for OpenShift, stolen tokens can be used to inject malicious images into CI/CD pipelines.

A lesson for any developer: never feed user-supplied values into a LIKE pattern without escaping, and use exact matching when you need to identify a record.

How to check and respond today

Red Hat lists every version of Quay 3 and Quay 5 as affected. If you run Quay, work through this in order:

  1. At the reverse proxy or load balancer, block the /keys endpoint for everything except trusted internal components.
  2. Search the audit logs for service_key_rotate and service_key_delete events where expiration_date is null.
  3. Remove any approved service keys you do not recognise.
  4. Install the fixed release. Until then, an attacker can add a new key the same way, so deleting one key does not last.

For CVE-2026-110697, while you wait to upgrade, Red Hat suggests limiting who can create organisations or namespaces containing an underscore, rotating robot tokens for any namespace that matches an underscore namespace, and watching for pulls or pushes that do not fit normal robot use. These steps only reduce exposure; the update is the only complete fix.

Note: the article reports that Red Hat's CVE page was not fully in sync with the advisories when checked, so confirm the exact fixed version for your branch in the advisory before upgrading.

Questions worth asking about registries other than Quay

Whichever registry you use, this incident prompts a few checks:

  • Is the registry reachable from the Internet or by untrusted clients, and does it need to be?
  • Do private images contain keys, passwords or .env files? Scan images for secrets, and treat any secret ever baked into an image as exposed if the registry is compromised.
  • Do your pipelines pin images by digest instead of tag? Digests make an overwritten tag detectable.
  • Who can create namespaces or organisations, and does that right need to be so broad?

Misplaced keys and tokens have caused other incidents too; see our post on 4,837 hijacked GitHub accounts used to steal CI/CD secrets. If your servers run Node.js, don't skip the recent patch for 16 Node.js vulnerabilities.

If you want to review your build, image storage and deployment process for a running system, look at the projects Besoft has delivered and talk to our engineers about the scope of a review.

Sources

  • The Hacker News, "Critical Red Hat Quay Flaw Lets Attackers Read and Overwrite All Private Container Images in a Registry", 12 November 2026: https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html