CRITICAL: Red Hat Quay Flaw Leaks Robot Tokens Across Tenants

Every few months somebody reminds us that the boring parts of a codebase are where the real damage hides. This week it is Red Hat Quay, and the boring part in question is a SQL LIKE clause that forgot an underscore is a wildcard. That single oversight lets any authenticated user on a shared Quay registry walk off with other tenants' robot account tokens, and with those tokens they can read, push and overwrite private container images that were never theirs to touch.

Red Hat tracks the bug as CVE-2026-110697 and rates it Critical with a CVSS 3.1 base score of 9.9. The vector string tells the whole story in shorthand. It is network reachable, low complexity, needs only a low privileged account, requires no user interaction, and breaks scope with high impact to confidentiality, integrity and availability. The advisory went public on November 11, 2026, alongside fixed builds for every supported branch. If you run a self managed Quay registry, this is a drop everything and patch it now situation.

What actually went wrong

Quay uses robot accounts as machine credentials. They are the things your CI pipelines use to push freshly built images and the things your Kubernetes clusters use as pull secrets. Robot names live under a namespace, so a robot in the acme organization looks something like acme+builder. When Quay lists the robots that belong to a namespace, it builds a SQL LIKE pattern from the namespace name and asks the database for every robot whose name matches.

The problem is that the code drops the namespace name straight into that pattern without escaping the LIKE metacharacters. In SQL, an underscore in a LIKE pattern does not mean a literal underscore. It means any single character. So an attacker who creates an organization called acme_prod is not only asking for robots in acme_prod. They are also asking for robots in acme-prod, acme1prod, acmexprod and any other namespace that differs by one character in that position. Quay obligingly returns the matching robot accounts along with their decrypted authentication tokens, because as far as the listing function is concerned, the caller owns all of them.

Red Hat classifies it as CWE-89, SQL injection, which is technically correct even though nobody is dropping tables here. This is the quieter cousin of classic injection. The query runs exactly as written, it just answers a much broader question than the developer intended. The flaw was found internally by Dave O'Connor at Red Hat and reported on October 14, 2026, so at least this one came from the home team rather than from an incident responder's worst week.

Why a token leak is a supply chain problem

It would be easy to read "robot token disclosure" and file this under information leaks. That would be a mistake. Robot accounts in most real deployments have write permission, because the whole point of a CI robot is to push images. Once an attacker holds a victim tenant's robot token, they can pull private images to hunt for embedded secrets, and they can push a modified image over an existing tag. If your deployments reference images by tag rather than by digest, the next rollout, autoscaling event or node replacement pulls the attacker's version and runs it with whatever privileges your workloads already have.

That is the path from a namespace name with an underscore in it to code execution inside someone else's production cluster. No exploit chain, no memory corruption, no zero click wizardry. Just a crafted organization name and an API call your web UI makes every time someone opens the robot accounts page. CISA's enrichment of the record reflects that, with an SSVC technical impact rating of total.

Who is affected

The exposure covers Red Hat Quay 3.9, 3.10, 3.12, 3.14, 3.15, 3.16, 3.17 and 3.18, along with the upstream Project Quay code those releases are built on. Red Hat also lists Red Hat Quay 5 and the mirror registry for Red Hat OpenShift 2 as affected, which matters because a lot of disconnected OpenShift environments lean on that mirror registry and rarely get the same patching attention as the clusters it feeds. Red Hat has already fixed Quay.io, so if you only consume the hosted service, your part of this is limited to token hygiene.

The risk is highest in genuinely multi tenant registries, where different teams, business units or customers share one Quay instance and organization creation is open to ordinary users. A single tenant registry with a handful of trusted administrators is less exposed, but do not take too much comfort in that. The attack only needs a low privileged account and the ability to create a namespace. A phished developer, a contractor account that never got cleaned up, or a self service signup option someone enabled during a proof of concept three years ago is all it takes.

Exploitation status

As of this writing there is no public report of exploitation in the wild, CVE-2026-110697 is not in CISA's Known Exploited Vulnerabilities catalog, and the EPSS probability sits under one percent. CISA's own assessment marks it as not currently exploited and not automatable. Normally that would push something down the queue. Here it should not. The fix is a matter of escaping two characters in a query, which means anyone who diffs the patched release against the previous one will understand the bug in about five minutes. Exploitation does not require any special tooling either. The window between "nobody is exploiting this" and "everybody is exploiting this" is going to be short.

What to do right now

Upgrade. Red Hat shipped fixed builds as Red Hat Quay 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 and 3.18.3 under errata RHSA-2026:99019 and RHSA-2026:99021 through RHSA-2026:99027. Red Hat is explicit that there is no other complete workaround, so anything short of the upgrade is just buying time.

Patching closes the hole, but it does not undo anything that already walked out through it. After you upgrade, rotate robot account tokens, starting with any namespace whose name could collide with an underscore containing namespace on the same instance. A quick query against the Quay database for organizations and users with an underscore in their names will tell you which patterns exist, and from there it is simple to work out which legitimate namespaces they would have matched. If you cannot tell who created those underscore namespaces or why, treat that as a finding in its own right.

If the upgrade has to wait for a change window, Red Hat suggests restricting who can create organizations or namespaces containing underscores, rotating tokens for colliding namespaces, and watching registry activity for pulls and pushes that do not match how each robot is normally used. Turning off open user creation and limiting organization creation to administrators is a sensible interim step for any shared registry, and honestly a sensible permanent one for most.

Detection ideas

Quay's audit logs are your friend here. Look for robot account activity from source addresses that do not belong to your CI runners or cluster nodes. Look for pushes to production tags outside your normal build times, and for pushes from robots that historically only ever pull. Compare the digests behind your important tags against what your build system says it produced, because a tag that suddenly points at an image your pipeline never built is about as clear an indicator as you will get. Recently created organizations with underscores in their names, especially ones that look like near misses of existing tenants, deserve a hard look as well.

On the deployment side, this is a good moment to finish that image signing project that has been sitting in the backlog. Pinning workloads to digests and enforcing signature verification with something like Sigstore cosign through an admission policy means a stolen robot token can still push an image, but your clusters will refuse to run it. That control would have turned this from a supply chain compromise into a noisy failed deployment.

The bigger picture

There is nothing exotic about this bug, and that is exactly why it is worth paying attention to. Wildcard characters in LIKE patterns have been tripping up developers since before containers were a thing, and the lesson keeps being the same. Any time user controlled input becomes part of a query, even a query that feels read only and harmless, it needs to be treated as hostile. Registries sit at the very top of the software supply chain. A small mistake in one of them flows downhill into every cluster that trusts it.

If an IT provider manages your systems

If your company runs containers, a Red Hat Quay registry may store the software images your systems depend on. These registries are often set up once and rarely patched. CVE-2026-110697 is rated Critical, and it lets anyone with an ordinary login steal other teams' access tokens and replace your images.

• Do we run a self managed Red Hat Quay registry or the OpenShift mirror registry, and who is responsible for it?
• Has it been upgraded to a fixed build, such as 3.18.3 on the 3.18 branch?
• After the upgrade, were the robot account tokens changed, and did anyone check the audit logs for image uploads nobody expected?

A good answer gives the version you are on and the date it was patched, and confirms the tokens were changed. If nobody can say whether you run Quay or who looks after it, co-managed IT can make sure that system has someone responsible for it.

If you are an IT provider yourself, see how we partner with MSPs.