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

OCI failed to validate VOLUME_WRITE permission on volume attach, letting any tenant attach and read/write another tenant's volumes given the OCID.

- Payout: Research
- Severity: critical
- Program: Oracle Cloud Infrastructure
- Credited: Wiz Research
- Disclosed: 2022-09-20
- Write-up quality: 8/10
- Original: https://www.wiz.io/blog/attachme-oracle-cloud-vulnerability-allows-unauthorized-cross-tenant-volume-access
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-attachme-oracle-cloud-vulnerability-allows-unauthorized-cross-tenant-volume-access
- Tags: domain:cloud impact:data-leak impact:integrity impact:privesc kind:research platform:threat-intel sev:critical tech:rest technique:source-review vuln:access-control vuln:auth-bypass vuln:misconfiguration

**Target:** OCI Block Volume / Compute volume-attachment API
**Root cause:** The AttachVolume operation did not validate the VOLUME_WRITE permission in the volume's compartment scope, and attachment was permitted across tenancies.
**Steps:**
1. Obtain target volume OCID (web search, GitHub, or low-privileged read in victim env).
2. Create compute instance in attacker tenant in same Availability Domain as target volume.
3. Run `oci compute volume-attachment attach --type paravirtualized --instance-id <attacker_instance_ocid> --volume-id <victim_volume_ocid>`.
4. Attachment succeeds despite lacking VOLUME_WRITE; mount volume and read/write contents.
**How found:** While building the OCI connector for Wiz, engineers noticed they could attach almost all block and boot volumes given only the OCID without explicit authorization, then confirmed it worked even across tenancies.
**Exploitation:** Attacker with a volume OCID spins up an instance in the same AD and attaches the victim's detached or shareable volume, gaining read/write to exfiltrate data, harvest cleartext secrets, or modify binaries for code execution when the volume is later mounted by the victim.
**Escalation:** Read secrets on volume to move laterally/escalate within victim tenancy; modify boot/block volume binaries to gain code execution on victim compute instances.
**Insight:** When testing cloud APIs, compare the documented per-resource permission (VOLUME_WRITE in the volume's compartment) against actual enforcement; try operations across tenancy boundaries and with only the resource identifier, since cross-scope checks are often the missing one.