Flaw Unlocks All Private Images in Red Hat Quay

A critical flaw in Red Hat Quay lets attackers read and overwrite all private container images, even without an account on default setups.

Red Hat Quay is a popular enterprise-grade container registry, used by organizations to store, build, and deploy their container images in a private, controlled environment. This week, Red Hat disclosed a critical vulnerability that completely undermines that control. As reported by The Hacker News, the flaw allows an attacker with any level of access to a Quay registry to read and overwrite all private container images across every repository. This effectively nullifies the security boundaries between different projects, teams, and tenants. The issue is especially severe because Quay enables anonymous access by default. On these common configurations, an attacker needs no credentials whatsoever to carry out the exploit. Even on systems where anonymous access is disabled, Red Hat confirmed that any user with a valid account, regardless of their permission level, can achieve the same result. In response, the company has released a series of patched builds for affected Quay versions and is urging all administrators to upgrade immediately.

At a technical level, the vulnerability represents a complete breakdown of the authorization and access control logic that is supposed to govern a multi-tenant registry. A container registry acts as a private library for a company's software components, known as container images, which package up application code and all its dependencies. The flaw allows an attacker to bypass these permissions entirely, essentially escalating their privileges to that of a global administrator for all image repositories. This grants two dangerous capabilities: read access and write access. With read access, an attacker can exfiltrate proprietary source code, intellectual property, and embedded secrets like API keys or database credentials that were mistakenly included in an image. With write access, the threat becomes even more severe. An attacker can overwrite existing, legitimate application images with their own malicious versions, effectively poisoning the software supply chain.

This vulnerability is a powerful illustration of the risks inherent in modern software supply chains and automated DevOps practices. A container registry is a central, high-trust component in any CI/CD (Continuous Integration/Continuous Deployment) pipeline. Development teams automatically push newly built images to it, and production environments, often managed by orchestration systems like Kubernetes, automatically pull the 'latest' version of an image for deployment. By compromising the registry, an attacker can hijack this automated workflow to distribute malware, ransomware, or backdoors across an organization's entire production infrastructure. This type of supply chain attack is far more scalable and difficult to detect than targeting individual servers. It follows the pattern of other major incidents like the SolarWinds breach, where a trusted software distribution point was compromised to deliver malicious code to thousands of downstream targets, turning a company's own infrastructure against itself.

The immediate and most critical action for any organization using Red Hat Quay is to identify all instances and apply the security patches without delay. However, this incident should also serve as a catalyst for a broader security review of container infrastructure. Teams should immediately re-evaluate their registry configurations, starting with disabling anonymous access unless it is absolutely essential for a public-facing workflow. Furthermore, this highlights the need for a defense-in-depth strategy that does not rely solely on the registry's own security controls. Implementing container image signing with open-source tools like Sigstore's Cosign provides a crucial secondary layer of verification. Signed images allow your deployment systems to cryptographically verify that an image was built by a trusted source and has not been tampered with since it was signed. This ensures image integrity from the developer's machine all the way to production, providing a powerful defense against a compromised registry or any other man-in-the-middle attack vector. As a next step, security teams should audit access logs for any unusual image pull or push activity that may indicate a past compromise.

This vulnerability breaks the fundamental security model of a private container registry, effectively turning it into a public one. For developers and security teams, it means any proprietary code, application secrets, or base images stored in Quay could be stolen or maliciously modified.

A compromised container registry creates a severe business risk, enabling attackers to inject malware directly into a company's software supply chain. This could lead to widespread system breaches, data theft, service downtime, and significant damage to customer trust.