AttachMe: critical OCI vulnerability allows unauthorized access to customer cloud storage volumes

Before it was patched, #AttachMe could have allowed attackers to access and modify any other users' OCI storage volumes without authorization, thereby violating cloud isolation. Upon disclosure, the vulnerability was fixed within hours by Oracle. No customer action was required.

In June, Wiz engineers discovered and reported#AttachMe, a major cloud isolation vulnerability in Oracle Cloud Infrastructure (OCI), prompting Oracle to patch the vulnerability within hours and without requiring customer action.

Potential impact—Before it was patched, all OCI customers could have been targeted by an attacker with knowledge of#AttachMe. Any unattached storage volume, or attached storage volumes allowing multi-attachment, could have been read from or written to as long as an attacker had its Oracle Cloud Identifier (OCID), allowing sensitive data to be exfiltrated or more destructive attacks to be initiated by executable file manipulation.

Remediation—Within 24 hours of being informed by Wiz, Oracle patched#AttachMefor all OCI customers. No customer action was required.

Key conclusions—Cloud tenant isolation is a key element in cloud. Customers expect that their data isn’t accessible by other customers. Yet, cloud isolation vulnerabilities break the walls between tenants. This highlights the crucial importance of proactive cloud vulnerability research, responsible disclosure, and public tracking of cloud vulnerabilities to cloud security.

#AttachMeis one of the most severe cloud vulnerabilities reported since it could have impacted all OCI customers. Cloud isolation vulnerabilities usually impact a specific cloud service. However, in this case, the impact is related to a core cloud service.

Wiz engineers found that attaching a disk to a VM in another account didn’t require any permissions. This means a potential attacker could have accessed and modified data from any OCI customer, and in some cases could have even taken over the environment.

The potential attack flow was simple:

Discover the ID (OCID) of a target victim's volume by searching the web or by using a low-privileged user permission to read the volume OCID from the victim's environment.

Initiate a compute instance in an attacker-controlled tenant located in the same Availability Domain (AD) as the target volume.

Attach the victim's volume to the attacker's compute instance, thereby gaining read/write privileges over the volume.

From there, a potential attacker could have performed numerous serious actions:

Exfiltrate sensitive data stored on the volume.

Search the volume for cleartext secrets in order to move laterally through the victim’s environment and/or escalate privileges.

Alter existing block volumes and boot volumes—e.g. by manipulating binaries—in order to gain code execution when the volumes were mounted on compute instances.

Oracle responded extraordinarily quickly when Wiz responsibly disclosed its discovery of#AttachMe. As an Oracle partner and customer, Wiz appreciates Oracle’s collaboration and rapid attention to this issue. Oracle thanked Wiz for discovering this vulnerability as part of itsJuly 2022 Critical Patch Update Advisory.

While building the OCI connector for Wiz, our software engineers noticed that it was possible to attach almost all block volumes and boot volumes to a compute instance, given their Oracle Cloud Identifier (OCID), without explicit authorization. After more testing, we realized that this was even possible when the volume and compute instance resided in different OCI tenancies! This meant that an attacker could gain access to a volume in another tenant (as long as they knew the OCID), and whoever owned the volume (the victim) would be totally unaware that someone else had read/write access to their data, since the compute instance and attachment would be in the attacker’s tenancy.

As described in the OCIdocumentation, a volume is a virtual disk that provides persistent storage space for compute instances. There are two types of volumes in OCI:

Block volume—A detachable block storage device that allows you to dynamically expand the storage capacity of an instance.

Boot volume—A detachable boot volume device that contains the image used to boot a compute instance and is usually created upon compute instance creation.

OCI supports multi-attachment of block volumes, meaning you can attach a single volume to multiple instances at the same time using theshareablefeature with read/write or read only permissions.

Attaching a boot or block volume to a compute instance from the CLI is straightforward, requiring only the volume and instance IDs:

oci compute volume-attachment attach --type paravirtualized --instance-id <instance_ocid>  --volume-id <volume_ocid>

Based on thepolicy reference,the required permissions for AttachVolume areVOLUME_WRITE,VOLUME_ATTACHMENT_CREATE, andINSTANCE_ATTACH_VOLUME. The instance and the volume do not necessarily need to be in the samecompartment.

Volume attachment is an OCI resource that resides in the compute instance’s compartment and describes an attachment of a volume to a compute instance. Permissions are applied to a compartment (and its compartment tree). Therefore,VOLUME_ATTACHMENT_CREATEandINSTANCE_ATTACH_VOLUMEare required in the instance’s compartment scope (in this case, the attacker’s compartment) andVOLUME_WRITEis required in the volume’s compartment scope (the victim’s compartment).

However, as we discovered, there was a gap in the validation of theVOLUME_WRITEpermission when attaching a volume, which made it possible to attach any volume without authorization. In addition, attachment was possible across different tenancies: we managed to attach a volume from one tenancy to a compute instance in another tenancy.

When an unauthorized user attempts to perform any operation on a volume, the service (correctly) returns an error indicating the user lacks the required permissions:

Figure 1: Attempting to access a volume using the CLI without sufficient permissions

However, before#AttachMewas remediated, attempting to attach a volume to a compute instance succeeded whether the user had sufficient permissions or not:

Figure 2: Successfully attaching the same volume that we did not have permissions to access

Once the volume was attached, we could view and modify its content.

The detailed requirements to exploit#AttachMewere:

The attacker must know the OCID of the target volume—While OCIDs are generally private, they are not treated as secrets, so this is easily achieved.

The attacker’s compute instance must be in the same Availability Domain (AD) as the target volume—This condition can be easily met as the number of availability zones is relatively small (up to three in some regions) and can therefore be enumerated.

The target volume must be either detached orattached as shareable—Detached volumes are relatively common because by default the boot volumes associated with terminated compute instances are not deleted. In addition, backup data volumes are often not attached to a running compute instance.

When an attacker gains read access to your volumes, the main risk is data breach. Volumes may contain sensitive information such as Personally Identifying Information (PII), secrets, and more.

Another risk is data manipulation and intrusion into your cloud network. Attaching a volume provides write access that could be used to manipulate any data on the volume, including the operating system runtime (by modifying binaries, for example), thus gaining code execution over the remote compute instance and a foothold in the victim's cloud environment, once the volume is used to boot a machine.

The potential attack paths include:

Privilege escalation within the Compartment or Tenancy—If an attacker managed to get initial access to a victim’s OCI environment,#AttachMecould have been exploited to further escalate privileges. An attacker would have been able to query all available volumes in the compartment to obtain their OCIDs, mount them, and read any sensitive information stored on them.

Cross-tenant access—A more impactful scenario is if an attacker managed to obtain OCIDs of volumes in a remote tenant.#AttachMecould have been used to gain initial access to the victim’s environment by reading sensitive information and long-lasting secrets that were stored in the target volumes. In addition, the attacker could have manipulated existing block volumes and boot volumes in a way that would provide the attacker code execution when the volumes were mounted on compute instances.

We consider both potential attack paths quite feasible given that OCIDs are generally not treated as secrets. Numerous OCIDs of both block volumes and boot volumes of various environments, including those of major companies, can be found via a simple online search.

It is also possible to find OCIDs of volumes that were published on GitHub, indicating that these IDs are indeed not treated as secrets by developers. Low-privileged users and third-party vendors with read access to the environment could obtain OCIDs very easily.

Upon discovering#AttachMe, we immediately disclosed our findings to Oracle, who investigated and fixed this issue in less than 24 hours. We were happy to collaborate with such a professional team.

June 6th, 2022—Wiz discovers the vulnerability

June 9th, 2022—Vulnerability reported to Oracle

June 10th, 2022—Oracle acknowledges report

June 10th, 2022—The vulnerability is fixed

Insufficient validation of user permissions is a common bug class among cloud service providers.  The best way to identify such issues is by performing rigorous code reviews and comprehensive tests for each sensitive API in the development stage. Oracle shared with us that they use static code analysis technology to detect such problems already in development and investigate known and reported issues to ensure the problematic pattern does not recur elsewhere in the codebase.

We also recommend performing service-specific penetration tests and participating in bug bounty programs, as these have proven effective with these types of issues.

#AttachMeis the latest in a long line of cloud isolation vulnerabilities discovered by the research community: recent examples include"ExtraReplica"— a cross-tenant database vulnerability in Azure PostgreSQLalso discovered by Wiz research, and across-tenant vulnerability in Azure Cloud Shelldiscovered by Chen Cohen from eBay’s pen testing team.Today, there is no clear process around cloud vulnerabilities enforced by the security community. Cloud vulnerabilities are typically not issued CVEs, so they are very hard for customers to track. Recently, researchers from Wiz along with other cloud security community members initiated theOpen Cloud Vulnerability & Security Issue Databaseto help cloud users and defenders monitor and track cloud vulnerabilities. If you are interested in contributing, you can check out theOpenCVDB GitHub.

Leonid Belkind, CTO of Torq, and Itay Arbel, PM at Wiz, explain how organizations can build a coherent Cyber Security Incident Response Plan using Wiz CDR to analyze cloud events and threat alerts in their context together with Torq's next-generation orchestration and automation capabilities.

How Wiz Research uncovered multiple related vulnerabilities in PostgreSQL-as-a-Service offerings from GCP, Azure, and others.

Just two years since its launch, Wiz protects hundreds of the world’s leading organizations by enabling them to build faster and more securely in the cloud

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings