Beyond Prompt Injection: Hacking Apple's Private Cloud Compute

Summary

Security researcher Drinor Selmanaj disclosed CVE-2026-20685, a path traversal vulnerability in darwin-init, the first userspace process (PID 1, root) that provisions Apple's Private Cloud Compute (PCC) nodes. The flaw allows a maliciously crafted cryptex archive to write files as root outside the intended extraction directory, undermining the privacy and security guarantees underpinning Apple Intelligence's server-side inference.^[1][7]

The research was conducted entirely within Apple's Virtual Research Environment (VRE), with no testing on production infrastructure. Apple rated the issue as information disclosure (CVSS 6.5), fixed it in PCC releases 5E290.3 and later, and awarded the researcher $150,000 under the Apple Security Bounty.^[1]

Beyond the file write, the researcher demonstrated meaningful impact by redirecting the splunkloggingd log forwarder to an attacker-controlled endpoint, exfiltrating CloudBoard daemon state and per-request inference metadata (request IDs, token counts, timing), and showed that PCC attestation does not measure the writable config files that drive runtime daemon behavior.^[1]

Attack chain

1. Malicious artifact crafting: The researcher built a single tar archive that is simultaneously a working path-traversal exploit and a structurally valid cryptex. It contains traversal entries prefixed with ../../../../db/ to escape into /var/db/, alongside a genuine cryptex bundle (Restore/BuildManifest.plist and a Restore/Cryptex/POC_DEMO set produced with Apple's pccvre cryptex create) so the fullyApplied check passes and boot completes.^[1]
2. Extractor selection bypass: darwin-init reads the first four bytes of a downloaded artifact to choose an extractor. A tar file's ustar signature sits at offset 257, so it matches no known magic and falls through to the generic extract(to:) function, which appends attacker-controlled archive entry names to the output directory without sanitization and with none of libarchive's security flags set.^[1]
3. Root file write during boot: During the boot window darwin-init runs as root and writes to the writable data volume before steady-state enforcement services start. Four levels of ../ reach /var/db/, which persists after the userspace reboot, allowing the attacker's files to survive on the node.^[1]
4. Telemetry redirection and exfiltration: A traversal entry writes /var/db/prcos/splunkloggingd/config-main.plist, whose existence triggers launchd to start splunkloggingd pointed at an attacker-chosen Server URL and Index. The listener received ~785 KB of CloudBoard state plus per-request PlaintextMetadata (bundleID, workloadType, requestID, automatedDeviceGroup) and Trusted Inference Engine token counts and timing when inference requests were driven through the node.^[1]

Disclosure timeline

How it works

darwin-init picks an archive extractor by reading only the first four bytes (magic). AEA1 and AA01 map to safe Apple extractors; anything else (tar/gz/bz2/zip/cpio) falls through to a generic extract(to:). Because a tar ustar signature is at offset 257, tar files evade the magic check and reach the generic extractor.^[1]

The extract(to:) function takes each archive entry's pathname directly from the archive and appends it to the output directory without any sanitization or validation, then sets extraction options (ARCHIVE_EXTRACT_TIME/PERM/ACL/FFLAGS) while omitting all of libarchive's security flags. As a result libarchive writes wherever the entry name points and returns ARCHIVE_OK.^[1]

Two intended controls fail to stop this: PrivateCloudOSValidator.validate(cryptexConfig:) is an empty function body in the published source, and the per-cryptex sha256 digest is optional so integrity checking can be omitted when the attacker supplies the configuration.^[1]

The extraction base is four levels deep (/var/tmp/darwin-init/cryptex/<name>/). Three ../ reach /var/tmp/ which the userspace reboot wipes, but four ../ reach /var/db/ on the writable data volume, which persists after reboot and is not measured by the attestation chain.^[1]

Affected versions and patch status

Key takeaways

• Securing an AI inference pipeline requires securing the entire provisioning and boot environment, not just the model — a decades-old path-traversal class (Zip Slip / CWE-22) undermined PCC's privacy guarantees.^[1][3]
• Attestation that measures installed software but not writable runtime configuration leaves a gap: an attacker who can persist files on the data volume can alter daemon behavior while remaining indistinguishable from a clean node during verification.^[1]
• Empty validation stubs and optional integrity digests are dangerous defaults; the PrivateCloudOSValidator.validate(cryptexConfig:) was an empty function and the per-cryptex sha256 was optional, removing the intended safeguards.^[1]
• A root file write during the boot window was escalated into a telemetry-exfiltration channel by redirecting splunkloggingd, exposing per-request inference metadata and token-count side channels.^[1]

Defensive actions

• Ensure PCC nodes run releases 5E290.3 or later, where Apple addressed CVE-2026-20685.: Apple fixed the path-traversal flaw in these releases; earlier releases allow root file writes outside the extraction directory.^[1]
• Enable libarchive's security flags and validate archive entry pathnames against the intended output directory before extraction.: The root cause was that extract(to:) appended untrusted entry names without sanitization and set none of libarchive's protective flags, permitting traversal writes.^[1]
• Treat writable runtime configuration files as part of node integrity, not just installed software.: PCC attestation measured only installed software, so a poisoned node with altered /var/db config files was indistinguishable from a clean one under pccvre attestation verify.^[1]