Back to Intelligence

Critical Red Hat Quay Registry Flaw Allows Unauthenticated Read and Overwrite of Private Container Images — Detection and Remediation Guide

SA
Security Arsenal Team
November 13, 2026
11 min read

Red Hat disclosed a critical vulnerability in Quay, its enterprise container registry platform, that allows an attacker who can reach a Quay registry to read and overwrite private container images in every repository hosted on it. The exposure is worse than a typical authorization bypass: Quay enables anonymous access by default, and while that feature is on, the attacker needs no account at all. Even in environments where anonymous access has been disabled, any user holding a valid account — including low-privilege or service accounts — can exploit the flaw, according to Red Hat's disclosure.

This is a software supply chain incident waiting to happen. A container registry is the source of truth for what runs in your Kubernetes clusters, OpenShift environments, and CI/CD pipelines. An attacker who can silently overwrite an image tag — say, your internal payments-service:latest or a base image consumed by dozens of builds — gains durable, high-fidelity code execution in production the next time an orchestrator pulls that tag. No phishing required, no endpoint malware, no noisy lateral movement. The registry itself becomes the delivery mechanism.

If you run self-hosted Quay (or Red Hat Quay on OpenShift), treat this as an emergency patch event. The rest of this post breaks down the risk, provides detection content for hunting unauthorized registry writes, and walks through remediation and hardening.

Technical Analysis

Affected Products

  • Red Hat Quay (self-hosted / on-premises container registry), including Quay deployed via the Quay Operator on OpenShift
  • Red Hat has released fixed builds for eight Quay releases, indicating the flaw spans a wide swath of currently supported versions. Consult the Red Hat security advisory and the Quay release notes for your specific stream to identify the exact fixed build for your deployment.

How the Vulnerability Works (Defender's Perspective)

Based on Red Hat's description, the flaw is an authorization enforcement failure in the registry's access control path. The critical details for defenders:

  1. Attack surface: Any network-reachable Quay registry. Because Quay ships with anonymous access enabled by default, an unauthenticated remote attacker — no credentials, no session — can interact with repositories that should be private.
  2. Impact: Both read (pull/dump private images, extracting secrets, source code, and internal tooling baked into layers) and write (push/overwrite image manifests and blobs in any repository). The write primitive is the catastrophic one: it enables tag-level image replacement, which downstream consumers will pull and execute trusting the registry's integrity.
  3. Exploitation prerequisites: Network access to the registry endpoint (typically TCP 443, 8443, or a load balancer fronting Quay). When anonymous access is disabled, any valid account suffices — meaning compromised CI service accounts, leaked robot tokens, or disgruntled insiders all become viable paths.
  4. Attack chain: Attacker enumerates repositories via the registry API (/v2/_catalog, /api/v1/repository) → pulls private manifests and layers for reconnaissance and secret harvesting → pushes a poisoned manifest over an existing tag (e.g., latest, stable, or a pinned version tag) → waits for Kubernetes/OpenShift image pull or CI build to consume the tampered image.

This is functionally an Insecure Direct Object Reference / broken access control condition at registry scale — every repository in the registry is in scope, not just one tenant's namespace.

Exploitation Status

At the time of writing, there is no confirmed public report of in-the-wild exploitation, and no public PoC has been widely circulated. However, container registry APIs are extremely well understood (the OCI Distribution Specification is public, and tools like docker, podman, skopeo, and crane make interaction trivial). The barrier to weaponization is near zero. Assume exploitation attempts will begin — or already have — against internet-exposed Quay instances. Run external attack surface scans today to find Quay endpoints you forgot were public.

Detection & Response

The highest-fidelity detection sources for this threat are (1) Quay/nginx access logs showing registry API write operations from unauthenticated or unexpected principals, (2) repository enumeration patterns, and (3) unexpected manifest pushes that change image digests outside your CI/CD windows. Ship Quay application and access logs to your SIEM via syslog/CEF if you aren't already.

Sigma Rules

YAML
---
title: Unauthenticated Write Operation Against Quay Registry API
id: 3f8a2b61-7c4d-4e59-a912-0b6d8e1f2a34
status: experimental
description: Detects HTTP write methods (PUT/POST/PATCH) against OCI registry v2 API paths where the authenticated identity is anonymous or absent, consistent with exploitation of the Red Hat Quay broken access control flaw allowing overwrite of private images.
references:
  - https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
  - https://attack.mitre.org/techniques/T1195/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.supply_chain_compromise
  - attack.t1195.001
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/v2/'
  selection_write:
    cs-method:
      - 'PUT'
      - 'POST'
      - 'PATCH'
  selection_api_path:
    cs-uri-stem|contains:
      - '/manifests/'
      - '/blobs/uploads/'
  selection_anon:
    cs-username:
      - '-'
      - 'anonymous'
      - ''
  condition: selection_uri and selection_write and selection_api_path and selection_anon
falsepositives:
  - Misconfigured CI pipelines pushing without credentials (should be investigated regardless)
  - Health checks (typically GET only; low risk)
level: critical
---
title: Mass Repository Enumeration on Quay Registry
id: 91c4e7d2-5a38-4f60-b824-6d1a9c3e7f05
status: experimental
description: Detects reconnaissance behavior consistent with an attacker enumerating all repositories and tags in a Quay registry, a precursor to bulk image theft or overwrite via the disclosed access control flaw.
references:
  - https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
  - https://attack.mitre.org/techniques/T1595/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.reconnaissance
  - attack.t1595
logsource:
  category: webserver
detection:
  selection_catalog:
    cs-uri-stem|contains:
      - '/v2/_catalog'
      - '/api/v1/repository'
      - '/tags/list'
  selection_anon:
    cs-username:
      - '-'
      - 'anonymous'
      - ''
  condition: selection_catalog and selection_anon
falsepositives:
  - Internal vulnerability scanners and registry inventory tooling (allowlist known scanner IPs)
level: high
---
title: Quay Config File Access by Non-System Process
id: 5d2b8f40-1e96-4a37-c215-8f3b7a9d6e18
status: experimental
description: Detects processes other than the Quay service stack reading the Quay config.yaml, which contains FEATURE_ANONYMOUS_ACCESS and secret_key material an attacker may target after gaining a foothold on the registry host.
references:
  - https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/11/14
tags:
  - attack.credential_access
  - attack.t1552.001
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains:
      - '/quay-registry/config.yaml'
      - '/conf/stack/config.yaml'
      - 'quay-config/config.yaml'
  filter_known:
    Image|endswith:
      - '/python'
      - '/gunicorn'
      - '/podman'
      - '/conmon'
  condition: selection and not filter_known
falsepositives:
  - Administrators cat-ing config during troubleshooting
  - Configuration management agents (Ansible/Puppet) — allowlist
level: medium

KQL (Microsoft Sentinel / Defender)

This hunt assumes Quay nginx/app access logs are ingested via Syslog or CEF. It looks for unauthenticated write attempts against the registry v2 API and bulk repository enumeration.

KQL — Microsoft Sentinel / Defender
// Hunt: Unauthenticated writes and enumeration against Quay registry API
let lookback = 7d;
let QuayEvents = union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(lookback)
    | where SyslogMessage has_any ("/v2/", "api/v1/repository")
    | extend RawLog = SyslogMessage),
    (CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where RequestURL has_any ("/v2/", "api/v1/repository")
    | extend RawLog = strcat(RequestMethod, " ", RequestURL, " user=", coalesce(SourceUserName, "-"), " status=", tostring(Activity)));
QuayEvents
| extend IsWrite = RawLog has_any ("PUT", "POST", "PATCH")
              and RawLog has_any ("/manifests/", "/blobs/uploads/"),
         IsEnum  = RawLog has_any ("/v2/_catalog", "tags/list", "api/v1/repository"),
         IsAnon  = RawLog has_any ("user=-", "anonymous", "\"-\"")
| where (IsWrite and IsAnon) or (IsEnum and IsAnon)
| summarize EventCount = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            SampleLogs = make_list(RawLog, 5)
         by Computer, SourceIP = coalesce(column_ifexists("SourceIP", ""), column_ifexists("HostIP", "")), IsWrite, IsEnum
| order by EventCount desc;

For environments sending Quay audit logs into a custom table, pivot on action values of push_repo, pull_repo, and change_repo_permission grouped by performer — flag any push events where the performer is $anonymous or an account that has never previously pushed to that repository.

Velociraptor VQL

If Quay runs on a Linux host you can instrument, this artifact checks the running configuration for anonymous access and inventories recent registry write activity from the nginx access log — two of the fastest triage steps for this flaw.

VQL — Velociraptor
-- Artifact: Quay Anonymous Access + Registry Write Triage
-- 1) Check whether anonymous access is enabled in Quay config
LET config = SELECT read_file(filename=path) AS ConfigText, path AS ConfigPath
FROM glob(globs=[
  '/etc/quay/config.yaml',
  '/opt/quay/config.yaml',
  '/quay-registry/conf/stack/config.yaml',
  '/**/quay-config/config.yaml'
], root='/')
WHERE ConfigText =~ 'FEATURE_ANONYMOUS_ACCESS'

SELECT ConfigPath,
       ConfigText =~ 'FEATURE_ANONYMOUS_ACCESS: true' OR
       ConfigText =~ 'FEATURE_ANONYMOUS_ACCESS: True' AS AnonymousAccessEnabled
FROM config

-- 2) Pull recent unauthenticated PUT/POST/PATCH against /v2/ from nginx access logs
UNION (
  SELECT parse_string_with_regex(string=line,
         regex='^(?P<src>\S+) \S+ (?P<user>\S+) \[(?P<ts>[^\]]+)\] "(?P<method>\S+) (?P<uri>\S+) [^"]*" (?P<status>\d+)') AS Parsed,
         path AS LogPath
  FROM glob(globs='/var/log/nginx/access*.log', root='/'),
       foreach(row={SELECT read_file(filename=path) AS content FROM scope()}, query={
         SELECT split(string=content, sep='\n') AS lines FROM scope()
       })
  WHERE Parsed.uri =~ '^/v2/'
    AND Parsed.method IN ('PUT', 'POST', 'PATCH')
    AND Parsed.user IN ('-', 'anonymous')
)

Remediation & Verification Script

Run this on the Quay host (or against the Quay config secret on OpenShift) to assess exposure and audit for indicators of tampering. Adapt paths to your deployment model.

Bash / Shell
#!/usr/bin/env bash
# Quay critical authz flaw - exposure assessment and hardening script
set -euo pipefail

echo "=== [1] Identify running Quay version ==="
if command -v podman &>/dev/null; then
  podman ps --format '{{.Names}} {{.Image}}' | grep -i quay || echo "No quay container via podman"
elif command -v docker &>/dev/null; then
  docker ps --format '{{.Names}} {{.Image}}' | grep -i quay || echo "No quay container via docker"
fi
# Record the version tag - compare against the fixed builds listed in the Red Hat advisory

echo "=== [2] Check anonymous access setting ==="
CONFIG_PATHS=("/etc/quay/config.yaml" "/opt/quay/config.yaml" "/quay-registry/conf/stack/config.yaml")
for p in "${CONFIG_PATHS[@]}"; do
  if [[ -f "$p" ]]; then
    echo "Found config: $p"
    grep -i "FEATURE_ANONYMOUS_ACCESS" "$p" || echo "  FEATURE_ANONYMOUS_ACCESS not set (default = ENABLED on vulnerable builds)"
  fi
done

echo "=== [3] HARDEN: explicitly disable anonymous access until patched ==="
# Add or set in config.yaml:
#   FEATURE_ANONYMOUS_ACCESS: false
# Then restart Quay. On OpenShift: patch the config bundle secret and roll the Quay pods.

echo "=== [4] Audit: anonymous write attempts in access logs (last 10k lines) ==="
for log in /var/log/nginx/access*.log; do
  [[ -f "$log" ]] || continue
  echo "-- $log"
  tail -n 10000 "$log" | grep -E '"(PUT|POST|PATCH) /v2/' | grep -E '^\S+ \S+ - ' | tail -n 50
done

echo "=== [5] Audit: catalog / enumeration activity from external IPs ==="
for log in /var/log/nginx/access*.log; do
  [[ -f "$log" ]] || continue
  grep -E '(/v2/_catalog|/api/v1/repository|tags/list)' "$log" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
done

echo "=== [6] Export current image digests for integrity baseline ==="
# For each critical repo, record manifest digests NOW so you can detect silent overwrites:
#   skopeo inspect docker://<quay-host>/<org>/<repo>:<tag> --creds user:token | jq '.Digest'
# Compare against digests recorded before the disclosure window.

echo "=== [7] Network exposure check ==="
ss -tlnp | grep -E ':(443|8443|8080)\b' || echo "No registry listeners found on standard ports"
echo "Confirm Quay is NOT reachable from untrusted networks (load balancer / firewall review)."

Remediation

  1. Patch immediately. Red Hat has released fixed builds for eight Quay releases. Pull the fixed build corresponding to your deployed stream from the Red Hat Customer Portal / registry.redhat.io, and follow the Red Hat security advisory and Quay release notes for exact version identifiers: https://access.redhat.com/security/security-updates/ — verify the running image digest after upgrade.
  2. Disable anonymous access now — do not wait for the patch window. Set FEATURE_ANONYMOUS_ACCESS: false in config.yaml and restart the registry. On OpenShift, update the Quay configuration secret and let the Operator roll the deployment. Note the residual risk from Red Hat's disclosure: even with anonymous access off, any valid account can exploit the flaw until patched, so step 3 matters.
  3. Reduce valid-account blast radius until patched: audit all accounts and robot tokens with any registry access; disable or rotate CI service accounts, stale robot tokens, and shared credentials; enforce least-privilege repository permissions so a compromised token cannot reach repositories it doesn't need.
  4. Verify image integrity. Export current manifest digests for every production-critical tag and compare them against digests from before the disclosure window (from your CI logs, SBOM tooling, or prior skopeo inspect output). Any tag whose digest changed outside a known deploy is a suspect overwrite — treat it as an incident: pull the image, diff layers, and check workloads that consumed it.
  5. Restrict network reachability. Quay should not be internet-facing unless absolutely required. Place it behind an authenticated ingress/VPN or IP allowlist, and confirm via external attack surface scanning that no forgotten Quay endpoint is publicly exposed.
  6. Enforce tag immutability and signed images. Enable repository mirroring/immutability features where available, and require image signature verification (Cosign/Sigstore, or Red Hat's Simple Signing) at admission time in Kubernetes/OpenShift so a tampered unsigned image is refused even if a registry write succeeds.
  7. Centralize logging. Ship Quay application, audit, and nginx access logs to your SIEM with retention covering the exposure window. The Sigma and KQL content above depends on this.
  8. Monitor for follow-on activity. If you find evidence of anonymous pulls of private images, assume secrets embedded in image layers (API keys, kubeconfigs, TLS private keys, .npmrc/.dockercfg files) are compromised and rotate them.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.