CVE-2026-117685 in Gitea
Summary
by MITRE • 11/01/2026
The OCI registry's cross-repository blob mount checked the target package against the token's `public-only` restriction, but checked the source blob only against the full account permissions of the token owner. A `public-only` token with `write:package` scope, whose owner can read a private package and write to a public package namespace, could mount a blob of the private package into the public package. The private blob, such as a container layer, could then be downloaded by anyone through the public package.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability described involves a critical authorization bypass within the OCI registry's cross-repository blob mount mechanism, specifically affecting how access permissions are validated during the copy operation between different repositories or namespaces. In standard OCI (Open Container Initiative) workflows, mounting blobs is an efficient method for duplicating image layers without re-uploading data, but it relies heavily on accurate permission checks to ensure that sensitive data does not leak into public-facing areas. The core technical flaw lies in the asymmetric validation of permissions: while the system correctly verifies whether the target repository respects the token's `public-only` restriction, it fails to adequately restrict the source blob based on the same scope limitations. Instead, the registry only checks if the token owner has general write access to the destination and read access to the source blob under their full account privileges, ignoring the specific constraints imposed by a restricted token type.
This architectural oversight creates a severe information disclosure risk where an attacker possessing a `public-only` token with `write:package` scope can exploit this discrepancy. Such tokens are typically intended for operations that only affect public resources, thereby limiting exposure of internal or private data. However, because the source blob check relies on the owner's full account permissions rather than the token's restricted context, an attacker who has read access to a private package and write access to a public namespace can mount blobs from the former into the latter. This effectively bridges the isolation boundary between private and public registries, allowing data that should remain confidential to be referenced in a publicly accessible location.
The operational impact of this vulnerability is significant, as it enables unauthorized exfiltration of sensitive container layers or other artifacts stored within private packages. Once a private blob is mounted into a public package namespace, any external actor can download the content by referencing the new public path. This could lead to the exposure of proprietary source code, internal configuration details, credentials embedded in images, or other intellectual property that organizations rely on keeping secure. The ease with which this can be achieved means that even users with limited privileges can inadvertently or maliciously compromise the confidentiality guarantees provided by private repositories.
From a classification perspective, this issue aligns with CWE-269: Improper Privilege Management and CWE-863: Incorrect Authorization, as the system fails to enforce the intended access control policies during the cross-repository operation. In terms of adversary tactics, this behavior resembles aspects of ATT&CK technique T1530: Data from Cloud Storage Object Discovery or more specifically data exfiltration via cloud storage misconfigurations, where attackers leverage permission inconsistencies to move sensitive data into accessible locations for later retrieval.
Mitigation strategies must focus on correcting the authorization logic within the blob mount handler. The registry should enforce that both source and destination operations adhere strictly to the permissions granted by the specific access token being used, rather than falling back to broader account-level privileges when dealing with restricted tokens like `public-only`. Additionally, implementing strict validation rules that prevent mounting blobs from private repositories into public namespaces unless explicitly authorized through a higher-privilege scope would close this gap. Regular security audits of registry configurations and automated testing for privilege escalation paths are also recommended to ensure that future updates do not reintroduce similar logical flaws in access control mechanisms.