The flaw is triggered by abrupt power loss (e.g. during brownouts or unstable charging), preventing the secure world and logging subsystems from initializing. Confirmed it on real A17 Pro device.

Curious if others can reproduce this, or if similar behavior exists in M-series chips.

These are not ephemeral or misinterpreted logs... they’re hard evidence that SecureROM and HAL subsystems are exposing debug logic in production mode. That shouldn't be possible unless the chip itself is violating its own trust enforcement model.

If this behavior is reproducible across multiple production devices, it's a class of vulnerability that Apple cannot patch in software. We're talking about a silicon-level debug bypass that persists without jailbreak, unsigned code, or tampering.

Strongly recommend pulling logs from known-good A16/A17 Pro devices and look for those same entries.

That’s like saying that if the circuit breaker melts, it might melt one next to it too, and certain outlets wont work anymore…

Only thing that fixes it, is a hard reboot.

I wonder if that is related to this flaw.

No evidence of any security issue is presented. Though it's certainly wanted to drum it as something major 'This is a high-severity, unpatchable design flaw'.

- SPU is not a processor, it's a generic term that encompasses multiple coprocessors.

- The log lines don't even mention the Secure Enclave Processor (SEP).

- Each line of log output is its own thing and there is no reason to think they have anything to do with each other.

- Those are not specifically serial logs. It is possible to get the same logs over serial, but only with a development unit, Security Research Device, or jailbreak.