While the blastdoor sandbox was a major architectural improvement, it seems vulnerabilities were still present either in the code it relies on, the sandbox policy itself, or due to complex memory corruption bypass techniques.

Some possibilities for how exploit could bypass protections of the blastdoor sandbox:

- The vulnerability was in an image decoding library that blastdoor calls, but which runs outside the sandbox. CoreGraphics frameworks are likely not sandboxed themselves. So memory corruption there could still lead to privilege escalation.

  * The CoreGraphics frameworks like CGImage are core system libraries that predate Apple's sandboxing technologies. They were likely not designed with sandboxing in mind.
  * These graphics libraries need to be able to access hardware acceleration features like OpenGL/Metal, read and write image files, and render to the screen. Sandboxing them would likely break many of those features.
  * Apple may have determined that completely sandboxing mature system frameworks like CoreGraphics would impose too much performance overhead across the OS.
  * As a result, for backwards compatibility and performance reasons, Apple seems to have exempted these core graphics libraries from being sandboxed processes.

- The sandbox profile may allow more syscalls or access than necessary. The syscall filter is still in "permissive" mode. So kernel escalation could still be possible.

- Payload encryption and upload to iCloud bypasses blastdoor. So compromise of an external service could have allowed running outside the sandbox.

More LLM generated nonsense I suspect