I really don't understand why people keep saying this sounds like an intentional backdoor... it looks a lot more like the ramifications of using an overly complex set of state transitions that end up with a bunch of spaghetti logic strewn between multiple processes and a ton of largely unrelated systems that, if you go through them in the wrong order with outstanding delayed actions (as caused by the animations of that power drop down), lead to an exploitable race condition.

This isn't Apple being nefarious: this is just Apple being "sloppy" (which I put in quotes, as when you have as many engineers as they do working on as many features as they are, with all of the user interface wedged into the same small set of displays, you are going to expect to have at least a few places like this, and honestly Apple generally does really well at avoiding them).

(As a similar example to this, for an unrelated reason, I just spent the last few hours pulling apart how they do the UI z-ordering of the lock screen, and it is a ton of one-off rules like "if I am adding the notification list, and I already have a battery image up, put it over the battery; otherwise, try to find a thermal warning, but first ask if it considers itself important enough to be rendered on top of the notifications; if not, then see if we have a headset charging display, and try to render on top of that...".)