Release workflow uses third-party Action pinned to mutable @master with registry credentials in scope

CWEs: CWE-1357, CWE-494, CWE-829 CVSS: 8.0 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H) Component: quay/quay-builder-qemu

Description The build-and-publish job logs in to quay.io with secrets.QUAYUSER / secrets.QUAYTOKEN (lines 32-37) and later invokes Noelware/docker-manifest-action@master (line 91). Pinning a third-party Action to a branch ref means the executed code is whatever the upstream maintainer (or anyone who compromises that repo) pushes next; it is re-resolved on every run. Because docker/login-action has already persisted registry credentials in ~/.docker/config.json, any code injected into the Noelware action can read and exfiltrate the Quay push token or push arbitrary images to quay.io/projectquay/quay-builder-qemu. The workflow also lacks a permissions: block, so the default GITHUBTOKEN is available to the same step.

Affected Locations - .github/workflows/build-and-publish.yaml:90-98 - .github/workflows/build-and-publish.yaml:32-37

Attack Pattern Upstream compromise of Noelware/docker-manifest-action master branch leads to exfiltration of the quay.io push token / publication of a trojaned quay-builder-qemu image consumed by all Quay build executors.

Remediation Pin the third-party Action to a specific commit SHA. Add a top-level permissions: block restricting GITHUBTOKEN to the minimum required scope.

--- Source: Ex-Wing security assessment, finding FIND-001

A flaw was found in Quay. A user configured in GLOBALREADONLYSUPERUSERS is able to view robot account tokens for repositories they are not a member of, allowing an attacker with read-only superuser privileges to impersonate any robot account.

A flaw was found in the Quay config-tool's GitLab OAuth validator. This vulnerability causes sensitive credentials, specifically clientid and clientsecret, to be transmitted as plaintext in URL query parameters during POST requests to the GitLab endpoint. This insecure transmission can lead to the disclosure of these credentials in various system logs, such as server access logs, reverse proxy logs, and other monitoring systems. An attacker with access to these logs could potentially obtain these credentials, leading to unauthorized information disclosure.

The Quay config-tool's GitLab OAuth validator in pkg/lib/shared/validators.go (line 804) places clientid and clientsecret as plaintext URL querystring parameters when making POST requests to the configured GitLab endpoint. This causes credentials to leak into server access logs, reverse proxy logs, WAF logs, CDN logs, and OpenTelemetry traces even when the endpoint is the legitimate gitlab.com. The GitHub OAuth validator correctly uses HTTP Basic Auth headers and is not affected.

A flaw was found in the Quay config-tool's LDAP and SMTP validation functions. An attacker with config editor access can exploit these functions, which make outbound connections to user-supplied endpoints without proper IP or host filtering. This allows the attacker to perform internal network reconnaissance from the Quay pod's network position, potentially mapping the internal network infrastructure.

A flaw was found in Red Hat Quay and mirror registry for Red Hat OpenShift. The log export feature in these products allows an authenticated user to specify an arbitrary callback URL. A backend process then makes server-side HTTP requests to this provided URL. This vulnerability, known as Server-Side Request Forgery (SSRF), could allow an attacker to send requests from the application's internal network, potentially leading to the disclosure of sensitive information.

There's a privilege escalation vulnerability in quay-app container for the Mirror Registry application, where an attacker with access to the containerized pod can escalate its privilege to root access within the pod environment.