The newly published technical account from Sentry researcher Drinor Selmanaj gives the advisory far more texture than Apple’s brief description. It describes a boot-time route to write attacker-selected files as
rooton a PCC node and then redirect PCC telemetry to an attacker-controlled endpoint. Apple has credited Selmanaj and Suresh Sundaram for the CVE, while Sentry says the report received a $150,000 Apple Security Bounty award.
But the headline version — “attackers write files as root” — needs an important qualification. Apple classifies the issue as information disclosure, with a CVSS 3.1 score of 6.5, rather than remote code execution or a full server compromise. The CVSS vector requires an attacker to hold a privileged or adjacent network position; it is not a flaw that can be reached by sending a malicious Apple Intelligence prompt, installing an app, or merely connecting to a PCC-backed service.
CVE-2026-20685 Was a Boot-Time Archive Extraction Bug
Apple’s advisory says the flaw was a path-handling issue in
darwin-init, PCC’s first userspace process. As PID 1,
darwin-initruns as root while a node is booting, retrieves configuration, downloads software packages known as cryptexes, installs them, and then performs a userspace reboot into PCC’s normal service state.
Selmanaj’s report says the vulnerable path appeared when the component selected an archive extractor. Apple’s own encrypted and unencrypted archive formats are recognized from the first four bytes of a file. Other archive types fell back to a generic extraction function that, according to the report, appended archive entry names directly to a target directory without enabling libarchive’s defenses against
../directory traversal.
Tar files were the useful format because their
ustaridentifier occurs at byte offset 257 rather than in the first four bytes inspected by
darwin-init. That caused a tar file to take the generic path. A malicious archive entry containing repeated
../components could therefore escape the intended extraction folder.
This is a familiar vulnerability class — CWE-22, commonly called path traversal or “Zip Slip” when archive extraction is involved — in an unfamiliar setting. The novelty is not the underlying bug; it is where it occurred: a root-privileged provisioning component in the boot chain of Apple’s privacy-focused AI servers.
Selmanaj says a simple traversal archive was not enough. PCC would fail its post-extraction checks and stall rather than finish booting. The reported proof of concept combined traversal entries with a structurally valid cryptex bundle, allowing the legitimate bundle to satisfy installation checks while traversal entries placed attacker-controlled files under
/var/db/, a writable area that survives the userspace reboot.
That distinction is why the bug warranted more than a routine directory-traversal classification. The write occurred before PCC entered its expected steady state, and the affected destination could influence services after the node booted.
The Attack Required Control of a Sensitive Network Position
Apple’s official language is deliberately narrower than the technical walkthrough: “An attacker in a privileged network position may be able to leak sensitive information.” The National Vulnerability Database records the same condition as an adjacent-network attack vector, with no required user interaction and no required account privileges, but with confidentiality impact only.
In practical terms, the attack described by Sentry depends on being able to influence the PCC node’s boot-time configuration or the software artifact it retrieves. In the Virtual Research Environment, that configuration is supplied by a host-controlled HTTP service specifically intended to let researchers test PCC behavior. That makes a strong proof of the vulnerable code path, but it does not establish that an ordinary internet attacker could reproduce the setup against Apple’s production fleet.
This is the central line readers should not lose: the report shows what can happen after a privileged network actor reaches a bootstrapping channel, not a public path into PCC from a user prompt or a device on the internet.
Apple’s CVSS assessment also assigns no integrity or availability impact. That does not mean the root file write was harmless. It means Apple’s validated impact was the potential exposure of sensitive data, rather than an established ability to alter PCC’s attested software image, execute arbitrary unsigned code, or disrupt the service.
Sentry’s reported $150,000 bounty is consistent with Apple’s published PCC bounty schedule. Apple offers up to that amount for an attack requiring a privileged network position that obtains request data or sensitive information outside PCC’s trust boundary. Apple reserves a larger $1 million tier for a remote attack on request data that ends in unsigned code execution with arbitrary entitlements inside the PCC software image.
Redirected Logging Was the Demonstrated Data-Exposure Path
According to Selmanaj’s research, the file-write primitive was used to create a configuration file for
splunkloggingd, PCC’s internal log forwarder. The altered configuration made the daemon send selected telemetry to a server controlled by the researcher after the node completed booting.
The report says this captured about 785 KB of CloudBoard state and node telemetry, then surfaced per-request metadata while inference requests were processed in the VRE. The reported fields included request IDs, workload details, device-group identifiers, token counts, latency information, and signals associated with speculative decoding.
That is significant because PCC’s privacy model does not rest solely on encrypting request contents. Apple also says PCC uses “sealed observability”: only specifically approved telemetry should leave a node. Apple has published source code for
splunkloggingdas one of the security-sensitive PCC components researchers can inspect, precisely because log filtering is part of the platform’s privacy boundary.
The report’s most consequential claim is therefore not that a file could be written beneath
/var/db/. It is that a writable configuration file could alter where logging went without changing the signed software Apple’s cryptographic attestation measures. In Selmanaj’s VRE experiment, the poisoned node produced an attestation result indistinguishable from a clean node because the installed software remained the same.
Apple’s PCC documentation describes attestation as the process by which a device checks that a node is running Apple-published software recorded in a public transparency log. That remains valuable protection against unauthorized code images. The Sentry finding illustrates a narrower limitation: software-image attestation does not necessarily attest to every mutable configuration file that can shape runtime behavior.
The distinction matters for security teams evaluating “confidential AI” claims from any vendor. A verified boot chain and reproducible server image can still leave a gap if privileged setup code writes mutable state that later services treat as authoritative.
Apple’s Fix Is Real, but Its Operational Scope Is Not Public
Apple’s release notes identify
darwin-init, name the flaw as CVE-2026-20685, credit the researchers, and state that improved validation fixed the issue in PCC Release 5E290.3. The NVD lists Private Cloud Compute versions earlier than 5E290.3 as affected and carries Apple’s description unchanged.
What Apple has not published is equally notable. The company has not disclosed when Release 5E290.3 reached every production node, how many nodes ran a vulnerable build, whether it detected exploitation, or whether the fix added path sanitization, enabled libarchive extraction safeguards, or changed the cryptex validation model. There is also no public indication that Apple changed PCC attestation to cover mutable data-volume configuration.
The public record does, however, support several reassuring points. Apple gave researchers a Virtual Research Environment capable of running genuine PCC images in a virtualized setting, and Selmanaj says all testing occurred there rather than against production infrastructure. CISA’s SSVC enrichment for the CVE records exploitation as “none,” automation as “no,” and technical impact as “partial.”
That combination places the bug in the category of serious, responsibly disclosed cloud-infrastructure vulnerabilities rather than an active mass-exploitation event. The timing also matters: Apple’s CVE record was published on May 18, 2026, while the detailed technical write-up emerged on August 10, after the documented fix was already available.
No End-User Patch Exists for a PCC Server Bug
For Apple Intelligence users, there is no mitigation checklist beyond keeping devices on supported software so they can use Apple’s current PCC trust and transparency mechanisms. PCC itself is operated by Apple, and Apple has not exposed a customer-managed PCC deployment that enterprises can upgrade to 5E290.3 themselves.
For administrators and security architects, the useful lesson is broader. Bootstrapping services, artifact fetchers, archive extractors, writable configuration directories, and telemetry forwarders belong inside the threat model for AI infrastructure. They are not plumbing outside the model-security conversation; they can decide whether the privacy controls around inference survive contact with a hostile network position.
CVE-2026-20685 is patched, and there is no public evidence it was used against Apple’s production service. Its lasting significance is that the privacy boundary of a cloud AI system was challenged by a decades-old archive-extraction mistake at boot — and the demonstrated effect was data exposure through trusted logging, not a flashy takeover of the AI model itself.
References
- Primary source: cyberpress.org
Published: August 10, 2026 at 8:55 AM UTC
Loading…
cyberpress.org - Related coverage: security.apple.com
Loading…
security.apple.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: security.apple.com
Loading…
security.apple.com - Related coverage: cdn.nca.gov.sa
Loading…
cdn.nca.gov.sa - Related coverage: apple.com
Loading…
www.apple.com - Related coverage: apple.com
Loading…
www.apple.com - Related coverage: nvd.nist.gov
Loading…
nvd.nist.gov - Related coverage: cve.org
Loading…
www.cve.org