External risk intelligence

OCI Registry Cross-Repository Blob Mount Vulnerability Allows Unauthorized Access to Private Packages.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-117685

The vulnerability affects an OCI registry, which is a service commonly deployed as an internet-facing or edge-accessible repository for container images. Because registries are frequently exposed to the public internet to facilitate image distribution and CI/CD operations, this functionality is commonly reachable from outside internal networks.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability in OCI registries allows unauthorized access to private data, potentially exposing sensitive container layers or other package contents to the public. This occurs when a specially crafted request bypasses access controls, enabling the mounting of private data into a public package. While the exact business impact is unconfirmed, the exposure of private information in a public repository carries inherent risks.

Private data can be exposed publicly.
Confirms potential for sensitive data leakage.
Assess relevance and confirm exposure.

Attack Path

How an attacker could exploit the issue

An attacker can leverage a specially crafted token to access private data within an OCI registry. By manipulating cross-repository blob mounts, they can effectively link sensitive information from a private package to a publicly accessible one. This allows any user to download the private data, such as container image layers, through the public package.

Entry condition: Publicly accessible registry with specific token permissions.
Trigger point: Mounting a private blob into a public package.
Resulting risk: Sensitive data leakage to the public.

Live Threat

Current exploitation, exposure, and threat context

Under specific conditions, a specially crafted token could allow a private package's data, such as a container layer, to be mounted into a public package. This could then expose the private data to unauthorized users who can access the public package.

Private package data could be exposed.
Mounting a blob into a public package.
Anyone could download private data.

Operational Fix

Recommended remediation, mitigation, and detection steps

This critical vulnerability in OCI registry blob handling requires immediate attention from teams managing container image repositories and the underlying infrastructure. The first practical step is to identify all instances of the affected OCI registry technology, determine their network exposure and business criticality, and locate the accountable owners. Remediation planning should then be prioritized based on this risk assessment.

Ownership: Infrastructure and Platform Teams
Verify first: Publicly accessible registries and critical data
Action: Plan coordinated remediation or vendor engagement

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Gitea OCI registry used for?

The OCI registry is a component of the Gitea platform that functions as a storage system for container images and related software packages. It allows development teams to push, pull, and manage these artifacts, enabling them to be shared across CI/CD pipelines and deployment environments. By serving as a central hub for container orchestration, it simplifies the distribution of software components needed to build and run modern applications.

What does CWE-863 mean for CVE-2026-117685?

CWE-863 refers to 'Incorrect Authorization.' In the context of this CVE, it means the software failed to properly verify that a user had permission to access a private resource before allowing an action. Specifically, the system checked the destination for a blob move but neglected to re-verify that the requester also had authorization to read the private source blob, allowing unauthorized cross-repository access.

How is the cross-repository blob mount triggered?

The vulnerability is triggered when a user with specific token permissions—specifically `public-only` access combined with `write:package` scope—executes a request to mount a blob from a private repository into a public one. The bug does not occur if the token lacks write access to the public destination or if the target repository is not configured for public access, as these conditions are required to link and expose the private data.

Why should I worry about this if my registry is internal?

Halo Surface Signal indicates that OCI registries are often intentionally deployed as internet-facing services to support external CI/CD workflows and image distribution. While internal-only registries have a smaller threat footprint, you should verify if your specific instance is reachable from the public internet. If it is exposed to the web, the risk of unauthorized access to private package data increases significantly.

What are the first steps to address this vulnerability?

Begin by auditing your infrastructure to locate all active Gitea OCI registry instances. Once identified, categorize them by their network accessibility, prioritizing those exposed to the internet. Determine the business sensitivity of the data stored within these repositories, identify the responsible owners for each instance, and prepare to coordinate updates or apply vendor-provided patches as part of your incident response plan.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.