Apple patches decade-old iOS zero-day, possibly exploited by commercial spyware
theregister.com
theregister.com
Remember when Apple touted the security platform all-up and a short-time later we learned that an adversary could SMS you and pwn your phone without so much as a link to be clicked.
KSIMET: 2020, FORCEDENTRY: 2021, PWNYOURHOME, FINDMYPWN: 2022, BLASTPASS: 2023
Each time NSO had the next chain ready prior to patch.
I recall working at a lab a decade ago where we were touting full end-to-end exploit chain on the same day that the target product was announcing full end-to-end encryption -- that we could bypass with a click.
It's worth doing (Apple patching) but a reminder that you are never safe from a determined adversary.
MDM? That doesn't surprise me. Do you want to know how _utterly_ trivial MDM is to bypass on Apple Silicon? This is the way I've done it multiple times (and I suspect there are others):
Monterey USB installer (or Configurator + IPSW)
Begin installation.
At the point of the reboot mid-installation, remove Internet access, or, more specifically, make sure the Mac cannot DNS resolve: iprofiles.apple.com, mdmenrollment.apple.com, deviceenrollment.apple.com.
Continue installation and complete.
Add 0.0.0.0 entries for these three hostnames to /etc/hosts (or just keep the above "null routed" at your DNS server/router.
Tada. That's it. I wish there was more to it.
You can now upgrade your Mac all the way to Tahoe 26.3 without complaint, problem, or it ever phoning home. Everything works. iCloud. Find My. It seems that the MDM enrollment check is only ever done at one point during install and then forgotten about.
Caveat: I didn't experiment too much, but it seems that some newer versions of macOS require some internet access to complete installation, for this reason or others, but I didn't even bother to validate, since I had a repeatable and tested solution.
I would happily pay Apple an annual subscription fee to run iOS N-1 with backported security fixes from iOS N, along with the ability to restore local data backups to supervised devices (which currently requires at least 2 devices, one for golden image capture and one for restore, i.e. "enterprise" use case). I accept that Apple devices will be compromised (keep valuable data elsewhere), but I want fast detection and restore for availability.
GrapheneOS on Pixel and Pixel Tablet have been anomaly free, but Android tablet usability is << Apple iPad Pro.
USB with custom Debian Live ISO booted into RAM is useful for generic terminal or web browsing.
apps: https://news.ycombinator.com/item?id=46993016 | https://news.ycombinator.com/item?id=46997970
Apple offers that to all customers who open up an enterprise account and direct billing line.
You can already do that?
Apple offers that to all customers who open up an enterprise account and direct billing line
What's the name of the feature for Apple Enterprise customers that would allow iOS 18 to be installed on a newly provisioned device today?Downgrades are not supported by Apple Business Manager MDM and there's no reference to downgrades on the Enterprise page, https://www.apple.com/business/enterprise/
Because you will be paying the full unsubsidized rate for any support needed for features not available to the mass market.
Its like how IBM will gladly send a team of senior engineers to help enterprise clients resolve every last possible request.
Edit: As compared to mass market features, where the economics dont work unless they’re close to 100% certain most users wont require any costly support.
- Signup for Apple Enterprise account with direct billing
- Buy one hardware device direct via Enterprise account
- Buy one MDM license for the hardware device
- Sign contract for support at $500/hr, no minimum commitment
- Get access to docs & tools for iOS 18 on new hardware (don't need support)
Apple Enterprise Developer account requires 100 employees minimum, but Apple Enterprise does not.If you're an Apple Enterprise customer, can you install iOS 18 on a new device today? It appears that enterprises can delay upgrade to iOS 18 post-enrollment, but cannot roll back to or provision iOS 18 on new hardware.
Would also make a great corporate / government product - I doubt they care about charging the average consumer for such a subscription (not enough revenue) but I can see risk averse businesses and especially government sectors being interested.
"Memory Integrity Enforcement" (2025), 250 comments, https://news.ycombinator.com/item?id=45186265
Memory Integrity Enforcement (MIE) is the culmination of an unprecedented design and engineering effort, spanning half a decade, that combines the unique strengths of Apple silicon hardware with our advanced operating system security to provide industry-first, always-on memory safety protection across our devices — without compromising our best-in-class device performance. We believe Memory Integrity Enforcement represents the most significant upgrade to memory safety in the history of consumer operating systems.
> has no clear evidence of an actual breachIf the perceived breaches during 5 years of using multiple generations of Apple devices were due to methodology errors leading to false positives, why did they stop after moving to 2025 Apple hardware with MIE and Apple-only radio basebands?
Sometimes there were anomalies in app logs (iOS Settings - Analytics) or sysdiagnose logs. Sadly iOS 26 started deleting logs that have been used in the past to look for IOCs.
Similarly, when you talk about it going away after a reset that seems more like normal app activity stopping until you restart the app.
Are you using a simple config profile on iOS to redirect DNS and if so how are you generating it ? Full MDM or what are you adding to the profile ?
Charles Proxy was only used to time-associate manual application launch with attempts to reach destination hostnames and ports, to allowlist those on the separate physical router. If there was an open question about an app being a potential source of unexpected packets, the app was offloaded (data stayed on device, but app cannot be started).
MDM was not used to redirect DNS, only toggling features off in Apple Configurator.
Right now it comes across as "just enough knowledge to be dangerous"-levels, meaning: you've seen things, don't understand those things, and draw an unfounded conclusion.
Feel free to provide specifics, like log entry lines, that show this breach.
To learn iOS forensics, try Corellium iPhone emulated VMs that are available to security researchers, the open-source QEMU emulation of iPhone 11 [1] where iOS behavior can be observed directly, paid training [2] on iOS forensics, or enter keywords from that course outline into web search/LLM for a crash course.
[1] https://news.ycombinator.com/item?id=44258670
[2] https://ringzer0.training/countermeasure25-apple-ios-forensi...
• Restore / Boot
• Software rendering
• Kernel and userspace debugging
• Pairing with the host
• Serial / SSH access
• Multitouch
• Network
• Install and run any arbitrary IPA
Unlike a locked-down physical Apple device. It's a good starting point.For all you know, the traffic you've observed and deem malicious could just as well have been destined for Apple servers.
appldnld.apple.com configuration.apple.com gdmf.apple.com gg.apple.com gs.apple.com ig.apple.com mesu.apple.com mesu.apple.com ns.itunes.apple.com oscdn.apple.com osrecovery.apple.com skl.apple.com swcdn.apple.com swdist.apple.com swdownload.apple.com swscan.apple.com updates.cdn-apple.com updates-http.cdn-apple.com xp.apple.com
There was no overlap between unexpected traffic and Apple CDN vendors.
After a few years, bought the 2025 iPad Pro to see if MTE/eMTE would help, and it did.
Not understanding every bit of traffic from your device with hundreds of services and dozens of apps running is not evidence of a breach.
Have you found unsigned/unauthorized software? Have you traced traffic to a known malware collection endpoint? Have you recovered artifacts from malware?
Strong claims require strong evidence imo and this isn’t it.
Apple traffic was isolated separately, https://news.ycombinator.com/item?id=46994394
Traffic outside that baseline could then be reviewed closely.
I agree with other posters that you seem to be capable of network level forensics, but you have said nothing to back up what you consider a device breach other than 'some cloud destined network traffic which disapears after a hard reset'.
In my experience of forensic reports, this link is tenuous at best and would not be considered evidence or even suspected breach based on that alone.
> GrapheneOS on Pixel and Pixel Tablet have been anomaly free, but Android tablet usability is << Apple iPad Pro.
iPad Pro with Magic Keyboard and 4:3 screen is an engineering marvel. The UX overhead of Pixel Tablet and inconsistency of Android apps made workflows slow or even impractical, so I eventually went back to iPad and accepted the cost/pain of re-imaging periodically, plus having a hot-spare device,
Guaranteed. I find it hard to believe state actors will not attempt this.
Flash paper is king when it comes to secrets I guess.
That said, we all get the same time on this earth. Spending your time helping various governments hurt or kill people fighting for democracy or similar is... a choice.
https://www.sysdig.com/blog/detecting-cve-2024-1086-the-deca...
And yes because their UI folks should be spending time on the kernel. What next? If Apple didn’t have so many people working at the Genius Bar they could use some of those people to fix security vulnerabilities?
Apple doesn't have unlimited money. It all gets allocated somewhere. Allocating it in places that don't improve security or usability or increase sales is, in this sense, a wasted opportunity that could be more efficiently allocated elsewhere.
Yes?
No, just like any other company they don’t have unlimited money and my point stands.
Ofc they could afford to, but they don’t. They could alo afford to if they had unlimited money, but in the latter case by definition they’d lose nothing by actually buying.
Given the absurdity of the scenario and its contrivance though I’m not sure what your point is. More money spent on security is good is my point. And if they had more money they’d have more money to spend on security. And if they didn’t spend money on dumb shit like virtue signaling then they’d have more money. That’s the reasoning.
If you had to spend 0.5% of your income for something in a year, would that adversely affect how you chose to spend the other 99.5%?
Lawful killing is, by definition, legal. It’s also justified in certain situations.
Disagree? Cool, so don’t work for the police or Cellebrite lol, but don’t try to impose your idiosyncrasies on others.
But again, your condescending tone proves my point. You and I don’t have the same values. That’s okay. But keep yours to yourself and I’ll keep mine to myself, right? That’s my point.
If you think never harming any person is the highest human aspiration, then great! I wish you well on that journey. I disagree though, and personally - as a matter of my own morality and philosophy about the world - I think the earth would be a much better place with maybe 1/2 the current population (assuming we could cull the right people). Avoiding causing harm to others isn't really something I care about, and I think there are more important and more interesting things to worry about. I also think killing is absolutely justified under certain conditions and I also think the world would be objectively better off if certain people didn't exist. We disagree about this, but that doesn't mean we aren't both acting ethically. We just have very different ideas about what is good and bad and right and wrong.
Both of us can act ethically despite holding those contrary positions and stay within our own logical frameworks. I hope that makes sense to you.
Now, once again the main point was that doing work for the police or hacking shit for governments is a legitimate occupation and is legal, even if it leads to somebody being executed or arrested or deported (in fact, those are also legitimate things that plenty of people have no problems with). Laws generally reflect society's overall views on some subject matter. Feel free to Google social facts and Durkheim and Hart and the rule of law and theory of laws. Stating such is to state objective facts. If you dislike those occupations, that's cool - some people dislike prostitution, but it's a legitimate and legalised occupation in many places. But your opinion on the matter doesn't delegitimise it, and frankly nobody wants to hear your casting judgment on others based on your own personal opinions. This is the issue with protestors today - nobody else cares, man. Leave people alone lol.
I agree any discussion about the morality of this is unlikely to be productive, but I could have told you that at the start. Maybe don’t bring ‘ought’ statements into a discussion that’s really about the ‘how’ - how this zero-day was exploited and/or patched is, after all, the point of the submission, not some moral discussion about whether white hats ought to be doing this sort of shit in the first place.
G’day.
Things like QubesOS can help, but it's quite high-effort to use and isn't compatible with any phone I know of.
I hate these lines. Like yes NSA or Mossad could easily pwn you if they want. Canelo Alvarez could also easily beat your ass. Is he worth spending time to defend against also?
Apple really need to open up so at very least 3rd parties can verify integrity of the system.
MTE is an Arm architectural feature. Apple integrated it, fine. That’s engineering work. But the implementation in Apple silicon and the allocator integration are closed and non-auditable. We have blog posts and marketing language, not independently verifiable source or hardware transparency.
So yes, they deploy mitigations. That doesn’t negate the fact that the trust model is opaque.
Hardening a class of memory bugs is not the same thing as opening the platform to scrutiny. Users still cannot independently verify kernel integrity, inspect enforcement logic, or audit allocator behaviour. Disclosure and validation remain vendor-controlled.
You’re treating ‘we shipped a mitigation’ as proof against ‘the system is closed and PR-heavy.’ Those are different axes.
If what you meant to say was "the system is closed and PR-heavy," I won't argue with that. But that's a very different statement.
The real stinker with Liquid Glass has been macOS. You get a half-baked version of the design that barely even looks good and hurts usability.
What are you seeing?
They have been doing this every year for the past several years: https://www.macrumors.com/2025/12/19/ios-18-forced-ios-26-up...
It's being noticed just now because iOS 26 has controversial UI/UX and many users don't want to update.
You're choosing to not have the update. And that's fine- own it.
So left to update to 26.3, device slows, battery life deteriorates and a new device needs to be ~~purchased~~ … errr rented.
Good that apple has a monopole else consumers would have a choice.
I can copy something on my macbook and paste that on my iphone - nice feature. Or to my iPad. I’m a sucker for interconnected technology, no hassle with transferring data between my devices.
Sure there are alternatives, but none that provide such integration amongst diverse class of devices. That’s the true monopole they have - unfortunately.
I didn't try, but yes: https://linuxphoneapps.org/services/kde-connect/
So there is a definite alternative. Why doesn’t anyone start Orange Inc. to provide a one-stop hardware solution using Linux. I mean a place where phones, laptops, tablets are sold that are setup to work together?
Why doesn’t Ubuntu (for example) move into selling integrated hardware solutions based on Linux - for the consumer market.
To be fair this can be replicated with LocalSend, albeit not as slick UX wise.
I mean it would be nice but it's not quite the same threats.
Also sure you could avoid crapware from Meta, Google and the likes but you will still could be exposed to nefarious programs via things like supply chain attacks (i.e. npm), or the developer turning coat or not realizing their app has an exploit, etc.
Linux also lacks a thorough permissions system unlike iOS/Android and the even more granular GrapheneOS.
Linux phones lack verified boot meaning persistent malware is trivial on linux devices. There is no MTE/MIE on Linux phones and even Google themselves say like 70% of malware spawns from memory exploits[1].
Also linux only really has block level encryption, not file based encryption like iOS/Android. It would be trivial for LEO to access your device unless it was totally powered off and then the only protection is LUKS. Or really even if you lose your phone and someone was so inclined to they could just extract all the data if it was powered on but on the “lock screen,” as most if not all desktop (and I’d imagine linux phone) environments do not actually do any encryption or anything when the system is locked, it’s just a cosmetic lock for all intents and purposes.
It would maybe be possible to somewhat mitigate that with cryptomator or somehow using fscrypt since that’s what Android uses but I dont know
Also even for basic things like clipboard protection, even with Wayland there are ways around it so that an app can read anything from the clipboard (not usually done for nefarious means in my experience, but it’s possible — see an app like Vicinae’s clipboard history and clipboard-centric features running on Wayland).
There’s more but this is like a short overview.
This doesn’t even get into people preferring Firefox on Linux which is light years behind Chromium based browsers in terms of security.
While it’s not a huge issue on desktop depending on how you view it, I would imagine phones see way more of people’s private data than their computers do and so I think it’s more beneficial to have higher security here than give that up for Linux.
—-
[1] https://security.googleblog.com/2024/10/safer-with-google-ad...
Librem 5 has a 3FF Smart card reader. Also, it can be completely wiped and reinstalled, ensuring that your phone is cleaned whenever you suspect a compromise.
> supply chain attacks (i.e. npm)
Nobody uses npm on a GNU/Linux phone. As the OP correctly mentioned, the whole security model relies on the trusted apps. See also: https://source.puri.sm/Librem5/docs/community-wiki/-/wikis/F...
> Or really even if you lose your phone and someone was so inclined to they could just extract all the data if it was powered on but on the “lock screen,” as most if not all desktop
I never heard about such possibility. Could you provide some details or links on how this could be done? AI says it's not really possible without very sophisticated instruments.
> It would maybe be possible to somewhat mitigate that with cryptomator or somehow using fscrypt since that’s what Android uses but I dont know
Indeed, GNU/Linux phones can and probably will improve their security with time taking some things from Android.
> Also even for basic things like clipboard protection, even with Wayland there are ways around it so that an app can read anything from the clipboard
You can't just say this without any evidence.
> This doesn’t even get into people preferring Firefox on Linux which is light years behind Chromium based browsers in terms of security.
Unless you switch off JavaScript, which is what I do.
A modern computer or smartphone contains many peripheral CPUs. E.g., the hardware that implements USB probably has one. Each of these peripheral CPUs runs its own software or firmware. "Completely wiping and reinstalling" only works if the compromise did not get into any firmware of any peripheral or did get in, but for some (miraculous) reason cannot reinfect software running on the main CPU.
There is a reason we used to hear constantly the advice to reinstall Windows, but no longer hear it: the old advice no longer works reliably.
So, not only is wiping and reinstalling more laborious and time-consuming than just rebooting a system with a verified boot chain, it is not as reliable at ridding the system of an infection.
What hollerith said.
> Nobody uses npm on a GNU/Linux phone. As the OP correctly mentioned, the whole security model relies on the trusted apps. See also: https://source.puri.sm/Librem5/docs/community-wiki/-/wikis/F...
npm was just an example of how open source projects can be infiltrated. “Trusted” apps
> I never heard about such possibility. Could you provide some details or links on how this could be done? AI says it's not really possible without very sophisticated instruments.
There’s nothing special here. Linux phones/desktops (including Purism in theory in the future, as it doesn’t have by default FDE yet according to that FAQ if it’s current), typically only utilize Full Disk Encryption via LUKS. Which is also the direction Purism sounds like they’re going as they have no mention of fscrypt or something like systemd-homed and you only enter a decryption PIN on boot (like is currently done with their laptops).
So with LUKS it only encrypts at the block level so the drive is fully unencrypted when it’s mounted and unlocked. A display manager’s lock screen only “locks” the device visually, it doesn’t / can’t re-lock the volume since it operates above LUKS. So if someone were to take your device while it was powered on in theory they could just extract everything without issue (although I’m not sure of what USB protections Purism has — there are things like USBGuard for linux, but that could be easily defeatable, I don’t know).
It’s why I mentioned something like systemd-homed because it provides a way for user directories to be re-encrypted on logout/lock and prevent this. fscrypt also can do this and is part of why LEO can fail to extract user data in AFU on android devices.
Sorry I kind of just dumped this all out I can elaborate more if needed.
> Indeed, GNU/Linux phones can and probably will improve their security with time taking some things from Android.
Ultimately this is my main problem with Linux phones. Eventually you come back to just re-inventing Android, maybe worse because you didn’t have the resources to speed run all of it’s security improvements, so who knows how long it’ll take Linux to catch up. I don’t know if I’m missing something but why not just fork AOSP, migrate it to a newer Linux kernel (since iirc AOSP is based on like a 4.xx linux kernel), and go from there? You’d have all the power management, security features etc and be detached from Google.
> You can't just say this without any evidence.
Maybe I overspoke here. More specifically a GNOME extension can definitely read from the clipboard/selections without a user knowing, like this one for example, which I used on my system running secureblue (which disabled xwayland by default):
https://github.com/dagimg-dot/vicinae-gnome-extension
https://github.com/vicinaehq/vicinae
But there are others like this one:
https://extensions.gnome.org/extension/4839/clipboard-histor...
Now these probably aren’t malicious, but I would now wonder if a “good” extension can turn coat and start doing that. Of course GNOME extensions really aren’t ideal and if you’re on KDE or something else it probably doesn’t affect you.
> Unless you switch off JavaScript, which is what I do.
There are still significantly more security benefits than just disabling JavaScript though (which imo is not realistic for most users just due to how the web is today, really we should just be able to disable V8 and use Drumbrake instead).
For example, Firefox on Android still lacks site isolated processes[1]. It also has no JIT sandbox or content sandbox and no type-based CFI. And unlike Chromium it seems like the Mozilla team doesn’t really have an interest in keeping up with ARMs latest security features and using them, such as Branch Target Identification and Pointer Authentication which Chromium takes advantage of[2]. Firefox has no progress on either of these[3][4].
Firefox also lacks a security-focused memory allocator, and cannot handle one (try using GrapheneOS’ hardened memory allocator (hardened_malloc) with any Mozilla apps on Linux or GOS).
—
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1565196
[2] https://developer.arm.com/community/arm-community-blogs/b/op...
Every software can be infiltrated that way, it's actually harder with open source.
> Firefox on Android still lacks...
But we were talking about regular GNU/Linux here, not android, right?
I mean yes. I guess in theory it’s harder with open source but that’s something that’s hard to track with statistics I’d imagine. Well, intentionally placed backdoors at least are for sure are way more likely to be discovered in open source than closed source.
> But we were talking about regular GNU/Linux here, not android, right?
Firefox on GNU/Linux is the weakest form of the browser security wise by far, even as a flatpak, as Mozilla treats it like the lowest priority platform despite being the browser of choice by the average Linux user. Firefox on Windows and macOS has security features that are barely in the brainstorming stage on Linux (due to a multitude a factors, some probably not the fault of Mozilla).
On Android it’s still worse in security than Chrome/Vanadium/Brave.
I think that's because they don't consider the apps in their app store to be malware despite doing things like starting a server on localhost to circumvent sandbox.
Deleted comment
Whether it's a walled garden of iOS, or relative openneds of Android, I don't think either can police everythign on anyone's behalf.
I'm not sure how organizations can secure any device ios or android if they can't track and control the network layer, period out of it, and there are zero carveouts for the OS itself around network traffic visibility.
The closest I've seen is an on-device VPN like Lockdown Privacy , but it can't block Apple bypassing the VPN.
https://lockdownprivacy.com/ | https://github.com/confirmedcode/Lockdown-iOS
iOS is one problem, but it goes for every other device/server/desktop/appliance that you use.
You can take a lot of precautions, and mitigate some risk, and ensure that operations can continue even if something bad happens¹, but you cant ever "be safe".
¹ "" There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know "" (Often attributed to Donald Rumsfeld, though he did not originate the concept.)
Know what bad can happen is difficult.
I don't know what "equally annoying" would be for a company and its customers, i.e. a fair compromise. But we need a law requiring companies open source their hardware within X days of end of life support.
And somehow make sure these are meaningful updates. Not feature parity with new hardware, but security parity when it can be provided by a software only update.
Otherwise a company in effect takes back the property, without compensation.
> ... decade-old ...
> ... was exploited in the wild ...
> ... may have been part of an exploit chain....
There is evidence that some people were aware and exploiting it.
Apple was unaware until right now that it existed, thus is a 'zero day' meaning an exploit that the outside world knows about but they don't.
The other commenter is right, there's a lot of overlap in the communities. It's strange to me that I was in the "field" a good 20 years before I ever thought it would be a career opportunity. This is not a complaint by any means. :-)
Edit: I meant iOS 18
But there were security updates for macOS 14 and macOS 15 released yesterday:
Can’t wait to see how much battery it eats.
I'd much rather not do that
edit: my original post wasn't clear I see - I meant I don't want to ditch the phones they've got and hope Apple releases an update for ios 16
Yeah, that makes sense. I hope you get an update for them, too.
They don't appear there organically.
dyld has one principal author, who would 100% quit and go to the press if he was told (by who?) to insert a back door. The whole org is composed of the same basic people as would be working on Linux or something. Are you imagining a mass of people in suits who learned how to do systems programming at the institute for evil?
Additionally, do you work in tech? You don’t think bugs appear organically? You don’t think creative exploitation of bugs is a thing?
Of course no one can admit it publicly.
But it is something that governments are known to proactively do.
You can get dirt on people a la Jeffrey Epstein. And use that to coerce them.
Stuxnet was pretty impressive: https://en.wikipedia.org/wiki/Stuxnet
It was a complicated product that many people worked in order to develop and took advantage of many pre-existing vulnerabilities as well knowledge of complex and niche systems in order to work.
[0] https://repefs.wordpress.com/2025/04/09/a-comprehensive-anal...
OTOH, how rational are spy agencies about such things?
But some just happen to work too well.
But governments do have blatant back doors in chips & software.
>I've heard rumors ...
So like, the comment you're replying to? This is just going in circles.
I trusted apple.
To what? Write 100% bug free software? I don't think that's actually achievable, and expecting so is just setting yourself up for appointment. Apple does a better job than most other vendors except maybe GrapheneOS. Mainstream Android vendors are far worse. Here's Cellebrite Premium's support matrix from July 2024, for locked devices. iPhones are vulnerable after first unlock (AFU), but Androids are even worse. They can be hacked even if they have been shut down/rebooted.
https://grapheneos.social/system/media_attachments/files/112...
https://grapheneos.social/system/media_attachments/files/112...
https://grapheneos.social/system/media_attachments/files/112...
> assuming you didn't set a 20 random character password
It doesn't have to be all random characters for good protection.
Note that the description "an attacker with memory write capability may be able to execute arbitrary code" implies that this CVE is a step in a complex exploit chain. In other words, it's not a "grab a locked iPhone and bypass the passcode" vulnerability.
Like, you couldn’t get a locked phone that hadn’t already been compromised to do anything because it would be locked so you’d have no way to run the code that triggers the compromise.
Am I not interpreting things correctly?
[edit: ah, I guess “An attacker with memory write capability” might cover attackers with physical access to the device and external hardware attached to its circuit board that can write to the memory directly?]