With iOS 26.2 Release, Apple Reverses Course on Shutdown.log

When iOS 26 was released back in September of 2025, we reported a change to the way the operating system handled the shutdown.log file: latest entry of processes that stalled the device shutdown, shutdown.log was completely overwritten with the new entry, erasing important evidence of historical Pegasus and Predator spyware infections many in the research and forensics relied on as an indicator of compromise (IoC) for versions of the spyware before 2023. Newer variants of these strains don’t leave these traces so modern detections rely on other sources of information.

While the spyware and detection methods have mutually evolved, the change is raising serious questions about Apple’s stance on visibility into the iOS kernel, as it effectively erased the historic record of Pegasus and Predator infections in many older devices.

Excerpts from a HackerNews thread discussing our iOS 26 shutdown.log blog post

The good news for the security community is that Apple has reverted to creating a new shutdown.log file when a device is restarted instead of replacing the existing one, starting with iOS 26.2. While this doesn’t undo the damage for devices that upgraded to previous versions of iOS 26, for anyone who waited in order to preserve shutdown.log files, it’s now safe to update those devices and we recommend you do as several CVEs were patched with that release as well as the most current version, 26.3.

This situation demonstrates the chokehold that Apple has on iOS security research and how one decision (or mistake?) can leave an entire ecosystem stranded. iVerify customers are able to detect Pegasus and Predator infections because our real-time data feed is built on top of specialized knowledge from leading iOS and engineering experts that can look beyond forensic artifacts. However, those experts are few and far between, and deep iOS knowledge is not widespread. This leaves organizations with limited options: 1) trust Apple that iPhones are secure out of the box, 2) use iVerify’s EDR, or 3) use open source tools to manually inspect phones for historical evidence of compromise. 

We’re incredibly proud of the product that we’ve built at iVerify, but not every company wants to use our solution, and they should have meaningful choices that offer real security value. No other vector of cybersecurity only has one vendor and we shouldn’t be the only ones in the iOS game with a scalable solution. How do we get there? A robust security API. There is precedent here; Apple already offers several for MacOS-based endpoints so the broader security community can get better insight into device activity and not have to choose between relying on scraps of information to verify kernel integrity or just taking Apple’s word that the device is safe. 

One of the most perplexing pieces to the lack of an iOS security API is that with each release, iOS and MacOS become more and more similar. One of our digital forensics and incident response experts teaches an Apple forensics class at SANS Institute and has been able to consolidate what used to be a two-section training for iOS and MacOS respectively into a single unit, spending just a few hours on iOS. Yet, despite being almost identical operating systems, only MacOS has a security API with Apple continuing to insist iOS is secure by default despite continual updates by the company to fix CVEs that are known to have been exploited in the wild including the CVE fixed in the most recent release, 26.3.

The call for a robust framework for iOS is growing from the broader security community, who after years of threat notifications and billions of dollars in commercial spyware development, are openly questioning Apple’s marketing claims that there have never been any widespread attacks against the iOS operating system. The lack thereof is becoming untenable to defend.

If you’re concerned about being targeted by spyware, we recommend putting your device in lockdown mode or request a demo with our sales team.