CVE-2026-27771: Authentication Bypass and Information Disclosure in Gitea Container and Composer Registries

CVE-2026-27771 is a critical security vulnerability within Gitea and its fork Forgejo that stems from missing authorization checks (CWE-862). The flaws reside in the platform's package management endpoints, specifically affecting the OCI-compliant container registry and the Composer package registry metadata API. By exploiting these weaknesses, an unauthenticated remote attacker can query, list, and download private container images or extract sensitive package source URLs without authentication.

The main attack vector is situated within Gitea's implementation of the Docker Registry HTTP API V2. The token distribution endpoint designed to authorize OCI distribution clients fails to evaluate the relationship between anonymous clients and private package resources. When the instance is configured to allow public access but hosts private container images, the container registry middleware exposes administrative-level image query capabilities to completely unauthenticated requests.

This exposure leads to a critical breach of confidentiality, as container layers frequently contain proprietary source code, hardcoded credentials, TLS certificates, and other environment configuration variables. Furthermore, the accompanying information disclosure flaw in the Composer API exposes internal dependency hierarchies and repository paths, enabling targeted supply chain attacks. This technical analysis explores the underlying programmatic flaws, the mechanics of exploitation, and defensive mitigations.

The root cause of the container registry authentication bypass lies in the ReqContainerAccess middleware handler located in the routers/api/packages/container/container.go source file. To support the Docker/OCI Distribution Specification, Gitea distributes JSON Web Tokens (JWTs) via the /v2/token endpoint to authenticate clients. When the global configuration parameter REQUIRE_SIGNIN_VIEW is set to false, unauthenticated users are assigned the identity of a ghost user with a unique user identification number of -1.

The middleware handler is designed to block unauthorized requests by evaluating the client's session state. However, the handler only restricts ghost users when the configuration variable RequireSignInViewStrict is explicitly enabled. If this strict sign-in view flag is disabled, the middleware validates the anonymous token and permits execution to flow directly into the registry routing endpoints.

Importantly, the middleware completely lacks logical validation checks to verify whether the ghost user possesses read permissions for the target repository owner's package space. The application does not check whether the repository has a public, limited, or private visibility status. Consequently, an anonymous request is treated as authorized, allowing arbitrary access to container catalogs and layer blob payloads.

A secondary, distinct root cause affects the Composer metadata API endpoint /api/packages/<username>/composer. The createPackageMetadataResponse function constructs metadata payloads for Composer dependencies by extracting repository information. The application unconditionally exposes the inner repository URL via the HTMLURL() function without performing any authorization checks against the calling user's permissions, leading to a direct leak of private repository pathways.

The vulnerable handler structure in Gitea's codebase did not validate ownership access bounds when evaluating anonymous requests. The conditional evaluation inside the ReqContainerAccess function only restricted access if strict sign-in was explicitly active.

// Vulnerable handler structure in routers/api/packages/container/container.go
func ReqContainerAccess(ctx *context.Context) {
    if ctx.Doer == nil || (setting.Service.RequireSignInViewStrict && ctx.Doer.IsGhost()) {
        apiUnauthorizedError(ctx)
    }
}

The vulnerability lies in the conditional check shown above. When ctx.Doer is a ghost user, the logical AND operator requires setting.Service.RequireSignInViewStrict to be true in order to execute the unauthorized error handler. When the strict configuration is false, Gitea skips the error handler entirely, allowing anonymous operations on any path.

The remediation patch (introduced in PR #37290) corrects this behavior by rewriting the APIUnauthorizedError function. The patch forces Gitea to lookup the target owner's visibility properties and globally require sign-in checks before configuring authorization headers:

@@ -125,8 +126,15 @@ func APIUnauthorizedError(ctx *context.Context) {
 	// container registry requires that the "/v2" must be in the root, so the sub-path in AppURL should be removed
 	realmURL := httplib.GuessCurrentHostURL(ctx) + "/v2/token"
 	ctx.Resp.Header().Add("WWW-Authenticate", `Bearer realm="`+realmURL+`",service="container_registry",scope="*"`)
-	// support apple container like: container registry login <gitea-host> -u
-	ctx.Resp.Header().Add("WWW-Authenticate", `Basic realm="Gitea Container Registry"`)
+
+	ownerName := ctx.PathParam("username")
+	owner, _ := user_model.GetUserByName(ctx, ownerName)
+	requireSignIn := owner != nil && owner.Visibility != structs.VisibleTypePublic
+	requireSignIn = requireSignIn || setting.Service.RequireSignInViewStrict
+	if requireSignIn {
+		// support apple container like: container registry login <gitea-host> -u
+		ctx.Resp.Header().Add("WWW-Authenticate", `Basic realm="Gitea Container Registry"`)
+	}
 	apiErrorDefined(ctx, errUnauthorized)
 }

The patched code retrieves the target package owner's profile based on the URL parameter. It evaluates whether the owner's visibility is non-public or if strict sign-in is globally enforced. If either condition is met, Gitea correctly demands authentication, preventing the unauthenticated ghost user session from proceeding.

Exploiting this vulnerability requires zero configuration privileges and no active user interaction. The attack begins with pre-flight capability enumeration to confirm the existence of the container registry endpoint. An attacker sends a standard GET request to /v2/ and observes the authentication challenge headers returned by the server.

Following verification, the attacker requests an OCI bearer token from /v2/token, passing a wildcard scope parameter. The server grants a JWT scoped to the ghost user session. Because the middleware fails to check package owner visibility relative to the ghost user, the attacker can use this token to query the global index catalog endpoint at /v2/_catalog.

Once the catalog is returned, the attacker enumerates all public and private image repositories hosted on the registry. The attacker then requests the manifests for a target private repository using the bearer token. This response returns a list of layer blob digests, which the attacker downloads individually using the blob download API. Extracting these layers locally reconstructs the target container filesystem, exposing internal files.

The impact of CVE-2026-27771 is severe, resulting in the complete loss of confidentiality for all private container images hosted on the affected Gitea instance. In typical devops workflows, container images contain compiled application binaries, proprietary source code scripts, and system configuration files. Attackers can analyze these files to identify secondary application vulnerabilities or extract hardcoded secrets.

Beyond intellectual property theft, container layers frequently contain embedded database credentials, API keys, TLS private keys, and cloud infrastructure environment variables. Access to these credentials can facilitate immediate lateral movement within the target network or cloud environment. This elevates the risk from simple information disclosure to full infrastructure compromise.

The CVSS v3.0 score is rated at 8.2 with a high confidentiality impact rating. Furthermore, the EPSS score places this vulnerability in the 98th percentile for exploitation probability, driven by the release of public proof-of-concept exploits. The low complexity of the attack coupled with the lack of authentication requirements makes this a highly attractive target for automated scanning and mass exploitation.

Immediate remediation requires upgrading the Gitea instance to version v1.26.2 or higher, which introduces proper authorization validations on both the container registry and Composer endpoints. For Gitea deployments managed via Docker, administrators should update the container image tag to 1.26.2 or the latest stable patch release. Systems should be restarted to ensure all active middleware handlers are updated.

If an immediate upgrade is not feasible, administrators can apply a temporary configuration workaround to mitigate the container registry bypass. By editing the global Gitea configuration file app.ini and enabling the strict sign-in view setting, the anonymous access path is blocked. This configuration is located in the [service] block as shown below:

[service]
REQUIRE_SIGNIN_VIEW = true

Note that applying this mitigation blocks all anonymous browsing of Gitea, forcing all users to authenticate before accessing any resources. Security teams should also monitor system logs for unauthorized requests targeting the /v2/_catalog or /api/packages/ endpoints, as these are clear indicators of potential reconnaissance or exploitation attempts.