Apple built Private Cloud Compute (PCC) to extend iPhone-grade privacy into the cloud, promising that server-side AI requests would be as protected as anything processed on-device.
That promise cracked when researcher Drinor Selmanaj, founder and CTO of Sentry, found a path traversal flaw in the code that provisions PCC nodes at boot, a bug now tracked as CVE-2026-20685, and was rewarded with a $150,000 Apple Security Bounty payout.
The finding, published through Sentry’s Applied Research Center (SARC), shows that even a system engineered around cryptographic attestation and sealed telemetry can be undone by a decades-old vulnerability class hiding in a boot-time file extractor.
PCC handles Apple Intelligence requests too demanding for on-device processing. Its privacy model rests on three pillars: nodes are stateless and retain no data across requests; every node is cryptographically attested against a public transparency log before a device trusts it; and all logging passes through sealed, pre-approved audit tables.
Selmanaj’s research targeted the seam between these guarantees: the boot sequence, before any of PCC’s steady-state protections are actually running.
The flaw lives in darwin-init, the root-privileged PID 1 process that configures a fresh PCC node: it downloads cryptexes (Apple’s signed software bundles), extracts them, and installs them before triggering a userspace reboot into the live system[web:6].
Selmanaj discovered that when an artifact’s file signature doesn’t match Apple’s encrypted or Apple Archive formats, darwin-init falls back to a generic tar/zip extractor that copies an archive entry’s pathname directly to disk without sanitization.

Because that extraction happens as root, before validation logic runs, a crafted archive entry containing ../../../../db/ sequences could escape the intended install directory and land files on the node’s persistent data volume, the exact CWE-22 path-traversal pattern first popularized by 2007’s Zip Slip bug.
The technical hurdle wasn’t just writing outside the sandbox it was doing so without breaking the node’s own integrity checks, which would leave it hung and useless.
Selmanaj crafted a single tar archive that smuggled traversal entries alongside a fully valid, Apple-tool-generated cryptotex bundle, so the node’s fullyApplied check still passed and the boot completed cleanly. Tested entirely inside Apple’s official Virtual Research Environment, the exploit planted a proof file as root on /var/db/, which survived the reboot untouched.
Selmanaj escalated the primitive by overwriting the configuration file that gates PCC’s internal log forwarder, splunkloggingd.
Because its LaunchDaemon starts the moment that file appears, redirecting it pointed the node’s telemetry, including CloudBoard job events and, once inference workloads ran, per-request metadata such as request IDs, device group tags, and token counts at a server under the researcher’s control.
Apple’s own code explicitly marks some of that metadata as data that “must not be logged publicly,” underscoring the severity of the leak.
Crucially, a nonce-controlled attestation comparison showed Apple’s verifier could not distinguish a poisoned node from a clean one: attestation measures installed software, not the writable-volume configuration files that actually drive runtime behavior.
Apple rated the issue as information disclosure with a CVSS score of 6.5, patched it in PCC Release 5E290.3, and credited Selmanaj and Suresh Sundaram in its release notes.
The timing matters: Apple used WWDC 2026 to unveil a substantially rebuilt Siri built on next-generation Apple Intelligence, with server-side inference routed through PCC, meaning the infrastructure this bug touched is about to carry far more user traffic.
As AI assistants increasingly depend on cloud inference, this disclosure is a pointed reminder that securing the model is not enough; the boot process, provisioning pipeline, and telemetry plumbing around it need the same scrutiny.