Beyond Prompt Injection: Hacking Apple's Private Cloud Compute Security researcher Drinor was awarded $150,000 for discovering CVE-2026-20685, a path traversal vulnerability in Apple's Private Cloud Compute (PCC) provisioning code, darwin-init, that allows attackers to write files as root and compromise the privacy and security guarantees of Apple Intelligence. The vulnerability, found through Apple's Virtual Research Environment, enables redirecting node telemetry to an attacker-controlled server. Apple has assigned the CVE and the researcher plans to release a detailed technical paper. Beyond Prompt Injection: Hacking Apple's Private Cloud Compute Drinor was awarded $150,000 for CVE-2026-20685 targeting Apple's Private Cloud Compute, the inference backbone of Apple Intelligence capabilities. This work is my contribution to Sentry https://sentry.security/?ref=blog.sentry.security 's AI Security research initiative, run through SARC https://sentry.security/resources/research-center?ref=blog.sentry.security , the Sentry Applied Research Center. Our SARC focuses on evaluating systems that carry the most consequence as AI moves into everyday technologies. Private Cloud Compute is a natural target for that work, since it underwrites the privacy guarantees behind Apple Intelligence. There will be a technical paper released that's more detailed in the coming weeks, so stay tuned Private Cloud Compute https://security.apple.com/blog/private-cloud-compute/?ref=blog.sentry.security is becoming ever more important as the core component of Apple Intelligence features. It is built so a server can process your data with close to the privacy guarantees your iPhone gives you on-device for AI inference requests. I found a path traversal in the code that provisions PCC nodes, darwin-init , that lets an attacker write files as root and compromises privacy and security guarantees in PCC. Apple assigned it CVE-2026-20685 https://nvd.nist.gov/vuln/detail/cve-2026-20685?ref=blog.sentry.security . I found the vulnerability through Apple's Virtual Research Environment https://security.apple.com/documentation/private-cloud-compute/virtualresearchenvironment?ref=blog.sentry.security . The exploit is pretty cool and involved writing files as root during boot and redirecting the node's inference and other telemetry to a server I controlled. I think it's a pretty cool find. Besides the exploit itself, I'll explain more about what PCC is and why its guarantees are important for Apple and integrating AI in its products. I then talk about the boot window, the vulnerable component itself, and finally the exploit and the impact related to it. What is PCC and how it's related to AI Private Cloud Compute is Apple's server-side infrastructure for the Apple Intelligence requests that are too large or complex to run on the phone. Apple's privacy claim for it rests on three important mechanisms. Stateless.A node processes a request in memory and keeps no user data across requests or reboots.Attested.Before your device sends anything, it verifies cryptographically, against a public transparency log, that the node runs only the software Apple published.Sealed observability.Logs and metrics pass through sealed audit tables, so only specific pre-approved fields leave a node. Definitions A few terms clarify the rest of the blog. - A PCC node is one server in the fleet, a hardened DarwinOS. - A cryptex is a cryptographically sealed extension, a signed bundle of code and data mounted onto a node at boot; PCC ships its operating system and services as cryptexes.is the first userspace process on a booting node, PID 1, running as root: it fetches the node's configuration, downloads and extracts the cryptexes, installs them, and triggers a userspace reboot into the running system. darwin-init - The VRE Virtual Research Environment boots a genuine PCC image in a VM so researchers can test it. - The trust boundary is Apple's line between inside PCC, where your data is protected, and outside, where it is not, and attestation is how your device checks that a node is genuine and running only published software before trusting it. The boot window: darwin-init runs as root A PCC node's first userspace process is darwin-init , PID 1, root. It resolves a configuration source, downloads the system cryptexes, extracts them, personalizes and installs them, then triggers a userspace reboot USR that brings up the steady-state services. Two facts about that boot window are important. First, darwin-init writes to the writable data volume as root before any service that enforces the node's steady-state assumptions is running. Whatever it leaves on disk is present when the node boots up. Secondly, Cryptexes install one at a time. Its checks compare the result against the requested configuration. If one cryptex fails to install, the check fails, and USR doesn't continue, leading to the node hanging with no services. PCC's Extractors When darwin-init downloads an artifact, it reads the first four bytes to pick an extractor. | Magic | Type | Extractor | |---|---|---| AEA1 | Apple Encrypted Archive | extractAppleEncryptedArchive | AA01 | Apple Archive | extractUncompressedAppleArchive | | anything else | tar / gz / bz2 / zip / cpio | extract to: | A tar archive's ustar signature sits at byte offset 257, well past the four-byte window. Since tar did not match a known magic, it falls through the default branch to the generic extract to: . The vulnerable function extract to: does this: js guard let cStr = archive entry pathname entry else { continue } let str = String cString: cStr // update entry pathname relative to output dir let pathname = path.appending str archive entry set pathname entry, pathname.description The entry name comes straight from the archive and is appended to the output directory without sanitation/validation. See how the extraction options confirm it: js let options = ARCHIVE EXTRACT TIME | ARCHIVE EXTRACT PERM | ARCHIVE EXTRACT ACL | ARCHIVE EXTRACT FFLAGS Those options preserve timestamps, permissions, ACLs, and file flags. However, none of libarchive's security flags were set resulting in libarchive writing wherever the entry name points and returns ARCHIVE OK . There are two controls that could have prevented this. The cryptex configuration passes through PrivateCloudOSValidator.validate cryptexConfig: , which in the published source is an empty function body. The per-cryptex sha256 digest is optional, so when the attacker supplies the configuration, integrity verification can be omitted. I took advantage of this fact. The extraction path The extraction base is four levels deep: /var/tmp/darwin-init/cryptex/