Red Hat Quay CVE-2026-110697 (CVSS 9.9): An Unescaped Underscore Lets One Tenant Read Another's Robot Account Tokens

DevSecOps · 2026-11-13 · By H.A

A SQL LIKE wildcard flaw in Red Hat Quay's robot account listing exposes other tenants' decrypted robot tokens to any user who can create a look-alike namespace, fixed in Quay 3.9.28 through 3.18.3.

What Happened

Red Hat has disclosed CVE-2026-110697, a critical SQL injection flaw in Red Hat Quay, the container image registry behind many private registries and the hosted Quay.io service. Red Hat rates it 9.9 out of 10 (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). The CVE was published on 11 November 2026. Red Hat has already fixed Quay.io and released patched builds for every supported self-managed Quay branch.

The issue was found internally by a Red Hat engineer. There are no reports of exploitation in the wild so far.

Technical Details

The bug is in how Quay lists robot accounts, the machine identities CI/CD pipelines and Kubernetes clusters use to push and pull images. When building the list, Quay creates a SQL LIKE pattern from the namespace name but doesn't escape SQL wildcard characters.

In a SQL LIKE clause, an underscore (_) matches any single character. That means:

• An attacker with an ordinary account who can create an organisation or namespace picks a name with an underscore where a victim's namespace has a different character.
• For example, a namespace called acme_prod would also match acme-prod or acmexprod.
• When the attacker lists their own robot accounts, the query also returns the victim namespace's robot accounts, together with their decrypted tokens.

Robot tokens are long-lived credentials that often have push rights. Whoever holds one can pull private images and may be able to push poisoned images into another tenant's repositories. That makes this a cross-tenant supply-chain risk, not just a data leak, which explains the "scope changed" rating and the near-maximum score. Red Hat classifies it as CWE-89 (SQL injection).

Who Is Affected

The highest risk is to multi-tenant Quay deployments where regular users can create their own organisations:

• internal platform teams offering a shared registry to many business units
• service providers and universities hosting Quay for several customers
• any Quay instance where self-service organisation creation is turned on

Single-tenant registries where only administrators can create namespaces are much less exposed, but should still be patched. Red Hat has also listed Red Hat OpenShift Update Service in the CVE record, so check its advisory for your product.

Patch Status

Red Hat has released fixes for these Quay versions:

• 3.9.28
• 3.10.28
• 3.12.24
• 3.14.10
• 3.15.9
• 3.16.7
• 3.17.7
• 3.18.3

Earlier builds on each branch are affected. Quay.io has already been fixed and needs no customer action for the vulnerability itself. Red Hat says there is no complete workaround other than updating.

What To Do Now

1. Upgrade to the fixed release for your branch. On OpenShift, update the Quay Operator and confirm the running image version.
2. Rotate robot tokens. If your instance is multi-tenant, assume tokens may already have leaked. Prioritise robots with push or admin permissions and any namespace whose name could collide through underscore wildcards.
3. Hunt for suspicious namespaces. List organisations created recently that contain underscores and closely resemble existing names.
4. Review audit logs. Look for image pulls or pushes by robot accounts from unexpected IP addresses, at unusual times, or against repositories the robot doesn't normally touch.
5. Restrict namespace creation until you patch. Limit who can create organisations, or block names containing underscores.

A simple starting point for spotting look-alike namespaces, using an exported list of organisation names:

# orgs.txt: one organisation/namespace name per line
grep '_' orgs.txt | while read n; do
  pat="^$(printf '%s' "$n" | sed 's/_/./g')$"
  grep -E "$pat" orgs.txt | grep -vx "$n" | sed "s/^/$n may collide with: /"
done

After patching, re-sign or re-verify critical images if your pipeline uses image signing. If you aren't sure a repository was untouched, compare image digests against your build records.

Why It Matters

Container registries are a central link in the software supply chain. Every cluster that pulls from them trusts what they serve. A flaw that lets any tenant read other tenants' deployment credentials undermines the isolation multi-tenant platforms are built on. The root cause is old and familiar: an unescaped wildcard in a LIKE query. Treating user-controlled names as plain text instead of patterns is easy to forget, and on a shared registry it nearly reached the top of the CVSS scale.

Quay administrators should patch this week and rotate credentials rather than wait for exploitation reports. Because the bug is now public, it is straightforward to reproduce for anyone who can create an account on an exposed instance.