CVE-2020-27838 is an improper access control vulnerability in Project Quay, the open-source container registry maintained by Red Hat, that allowed unauthorized users to gain access to images stored in private repositories. For any organization running a self-hosted container registry, this class of bug is about as serious as it gets: a private image often contains proprietary application code, embedded credentials, internal configuration, and infrastructure details that were never meant to leave the organization's trust boundary. When access control logic in the registry itself breaks down, the confidentiality guarantees that teams rely on to safely store and distribute container images collapse with it.
This post walks through what CVE-2020-27838 actually is, which Project Quay deployments were affected, what we know about its severity, and — most importantly — what teams should do about it, whether they're still running an old Quay instance or simply want to harden their container registry posture against this whole category of failure.
What Happened: The CVE-2020-27838 Vulnerability in Project Quay
Project Quay is an enterprise-grade container registry that stores, builds, and distributes container images, and it underpins registry functionality in Red Hat's OpenShift and Quay.io ecosystems. Organizations use it specifically because it supports fine-grained repository visibility: images can be marked public or private, and access to private repositories is supposed to be gated by explicit permissions — team membership, robot account credentials, or user-level grants.
CVE-2020-27838 is tracked under CWE-284, Improper Access Control. At its core, the flaw meant that the authorization checks Quay was supposed to enforce before serving image data — manifests, tags, and layer blobs — did not fully validate that the requesting user actually had permission to view the repository in question. In practice, this created a path for a user without legitimate access to a private repository to retrieve image content that should have been restricted to authorized accounts only.
The practical impact is straightforward but severe: private image exposure. Any image pushed to a private repository under an affected Quay instance was potentially retrievable by a party who should never have had visibility into it. Because container images frequently bundle far more than "just code" — think API keys hard-coded during a rushed build, internal hostnames, TLS certificates, or dependency manifests that reveal your internal architecture — a break in registry-level access control can cascade into a much broader secrets and information disclosure incident.
Affected Versions and Components
CVE-2020-27838 affects Project Quay (Red Hat Quay) deployments predating the fix Red Hat shipped as part of its Quay 3.3.x maintenance line. The issue lives in the registry's access-control enforcement layer, meaning it is not tied to a specific storage backend, authentication provider, or deployment topology — any self-hosted Quay instance relying on repository-level privacy settings to protect images was potentially exposed, regardless of whether it sat behind OpenShift, ran standalone, or was deployed via the Quay Operator.
Because Project Quay is frequently used as internal, org-wide infrastructure rather than a public-facing service, the practical exposure for any given deployment depends heavily on network placement: instances reachable only from a trusted internal network had a smaller attack surface than internet-exposed registries, but "private repository" is a promise the registry makes independent of network location, and this vulnerability broke that promise at the application layer.
Severity, Exploitability, and Exposure Context
Red Hat classified CVE-2020-27838 as an access control weakness with a confidentiality-only impact — the flaw allows unauthorized reading of private image data but does not, by itself, provide a path to modify images, escalate privileges, or take over the registry. That narrower blast radius is reflected in its Red Hat/NVD severity rating, which sits in the medium range rather than critical, since exploitation requires an account or access path into the registry rather than fully unauthenticated, internet-wide exploitation.
CVE-2020-27838 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no indication of widespread in-the-wild exploitation tracked publicly for this issue. As with many registry-layer access control bugs that require some existing foothold or account context to exploit, its EPSS (Exploit Prediction Scoring System) likelihood has stayed low compared to remotely exploitable, unauthenticated flaws. That said, low EPSS and absence from KEV should not be read as "safe to ignore" — for organizations whose entire threat model around container images rests on the private/public distinction, this vulnerability directly undermines that model, and the cost of a quiet private image exposure (leaked source, leaked secrets) can be high even without a flashy exploitation chain.
Disclosure Timeline
CVE-2020-27838 followed Red Hat's standard coordinated disclosure process for Project Quay: the improper access control issue was identified and reported to Red Hat Product Security, assessed internally, and assigned a CVE identifier as part of a batch of Quay hardening fixes addressed around the same release cycle. Red Hat resolved the issue in an update to the Quay 3.3.x release line, publishing the fix alongside an advisory and the corresponding CVE record so that downstream operators — including organizations running Quay via the Quay Operator on OpenShift — could identify affected deployments and apply the patched version. As with most registry CVEs of this kind, the operationally important date for defenders isn't the disclosure date itself, but the date their own instance was actually upgraded past the vulnerable code path.
Remediation Steps
If you are running Project Quay, or inherited a Quay deployment as part of an OpenShift or Quay.io-adjacent environment, treat CVE-2020-27838 as a prompt to verify both your patch level and your broader private image exposure posture:
- Upgrade Project Quay to a release that includes the fix for CVE-2020-27838 and confirm the patched version is actually running in production, not just staged. Version drift between environments is one of the most common reasons legacy access control CVEs stay exploitable long after a patch exists.
- Audit repository visibility settings. Enumerate every repository marked private and confirm the permission list matches intended access — teams change, robot accounts get over-provisioned, and stale grants compound the risk of any access control weakness.
- Review registry access and pull logs for the affected period for anomalous pulls of sensitive private repositories from unexpected users, service accounts, or IP ranges.
- Rotate anything that may have been exposed. If a private image could plausibly have been pulled by an unauthorized party, treat embedded credentials, API keys, and certificates in that image as compromised and rotate them, regardless of whether you have direct evidence of exploitation.
- Apply least privilege to registry accounts and robot accounts. Reduce the number of identities that can reach private repositories at all, so that a future access control bug has a smaller population of potential abusers to worry about.
- Layer network controls on top of application-level access control. Don't rely solely on the registry's internal permission model — restrict which networks and services can reach the registry API in the first place, so a flaw like CVE-2020-27838 doesn't automatically translate into broad exposure.
- Scan images continuously, both for vulnerabilities and for accidentally embedded secrets, so that even if access control fails again in the future, the images themselves are less of a liability.
How Safeguard Helps
CVE-2020-27838 is a good example of why software supply chain security can't stop at scanning code repositories — the container registry itself is part of the supply chain, and a flaw in its access control logic is a direct threat to every private image it stores. Safeguard is built to close that gap.
Safeguard continuously monitors the container registries and artifact stores in your environment — including self-hosted platforms like Project Quay — for exactly this class of risk: misconfigured or broken access control that could lead to private image exposure. Rather than waiting for a manual audit, Safeguard tracks repository visibility, permission changes, and pull activity so that unexpected access to sensitive images surfaces as an actionable alert, not a post-incident discovery.
Safeguard also correlates known vulnerabilities like CVE-2020-27838 against your actual deployed infrastructure, flagging outdated or vulnerable registry versions before attackers can take advantage of them, and prioritizing remediation based on real exposure rather than CVSS score alone. Combined with continuous secret scanning and image provenance verification, Safeguard helps teams catch the downstream consequences of an access control failure — hard-coded credentials, leaked internal details, unverified image sources — even in cases where the underlying registry vulnerability has already been patched elsewhere.
For teams running Project Quay or any container registry as core infrastructure, the lesson from CVE-2020-27838 is simple: access control assumptions need continuous verification, not one-time trust. Safeguard is designed to provide exactly that verification, so private really does mean private.