This was a bug that left it cached on the device. Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.
If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
> Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.
>If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
This incorrect on two counts:
1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this
2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext.
Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.
Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.
Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device.
That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android.
A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local.
An app that cares about privacy wouldn't send anything more than a poll instruction over FCM.
As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache.
From the linked article:
> The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal.
The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust.
This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal.
The "bug" discussed in the article is only part of the problem.
The main problem, which is notifications text is stored on a DB in the phone outside of signal, is not addressed. To avoid that you have to change your settings.
In this case, the defendant had deleted the signal app completely, and that likely internally marks those app's notifications for deletion from the DB, so the bug fixed here is that they were not removing notifications from the local database when the app that generated them was removed, now they do.
Impact: Notifications marked for deletion could be unexpectedly retained on the device
Description: A logging issue was addressed with improved data redaction.
CVE-2026-28950
They classify this as "loggging issue" so it sounds like notifications were not actually in the database itself but ended up in some log.
Oh, I was originally confused about this because I had thought the push notifications were end-to-end encrypted, so they couldn't be cached in readable form by the push notification service, and only decrypted by the app on device upon receiving the notification. But it seems like after the notification was decrypted by the app and shown to the user using OS APIs, the notification text was was then stored by the OS in some kind of notification history DB locally on the device?
In privacy circles, this was always known, as Google/Apple often sends notification content to their servers (which means that it bypass the App realm).
I expect that Signal encrypts the notification data prior to sending it to Apple, then decrypts it on-device using a Notification Service Extension – this is a common pattern to avoid trusting Apple with any sensitive data.
That would mean Apple stored the cleartext on-device after decryption.
Signal doesn’t provide anything in the message other than… “there are pending messages.” Signal wakes up, fetches them, then generates notifications on the phone itself.
It's not new that push notifications should be presumed to be insecure, with their content passing through - and probably persisted - outside the app sandbox and anything in control of in-app encryption.
Apple should have fixed this long ago (not that you can trust a closed system), but Signal should also have strong guardrails & warnings around allowing message content in push notifications.
This makes me wonder: Cellebrite makes tools for law enforcement to break into iPhones, likely exploiting weaknesses/vulnerabilities. Does Apple buy Cellebrite’s tools and reverse engineer them? Or would they not have a way of acquiring them legally?
Not only that, but iOS 18.7.8 actually seems to be available to devices capable of running iOS 26 without any workarounds, unlike 18.7.3 through .6. It makes me wonder if those intermediate releases really were supposed to be available but weren't due to some issue on the distribution side that no one bothered to fix.
Very serious vulns were being exploited in the wild, I think that's what forced their hand. I don't think Apple ever had a discrepancy like the one with iOS 18.7.3 through .6 being held back.
For those on iOS 18, beware that the update to iOS 18.7.8 will toggle Automatic Updates back on. Make sure to switch it back off so you don't wake up to a nasty surprise when iOS 26 is non-consensually forced onto your iPhone.
I think that was another attempt by Apple to push users to iOS 26, but after seeing how many people with compatible devices refuse to upgrade, they finally caved in and provided an update.
They caved, but they're still pulling out new tactics to trick users into installing iOS 26.
The new iOS 18 update will _also_ toggle Automatic Updates back on. I had it happen just now on my 13 Mini against my will. I had to go back into settings and very carefully navigate to disable automatic updates.
There seems to have been a change of mind, maybe also due to the severity of the exploits. The non-availability of security updates for models that are upgradable to a newer major version has been Apple's practice for many years now.
The way major upgrades are presented in the Settings UI makes it clear that users installing these security updates while not upgrading to a newer major version do so very intentionally. So Apple is now supporting these users deliberately.
Avoid iOS 26 at all costs. I was forced to update to it because I needed to factory reset my phone, and it's super buggy. I'm not even one of those people harping on the Liquid Glass design decisions, those are w/e, the problem is just that the phone routinely freaks out doing basic tasks like trying to open the camera app or close the keyboard. They should roll it back.
This was already the case for 18.7.7. However, after turning automatic updates off in 18.7.7, after updating to 18.7.8 it remained off (reproducibly on several devices I updated). Maybe there is a one-time flag that is set so that after turning off automatic updates after having been turned on automatically, they aren't automatically turned on again on subsequent updates.
This was a bug that left it cached on the device. Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.
If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
> Apple and Google have put themselves in the middle of most notifications, causing the contents to pass through their servers, which means that they are subject to all the standard warrantless wiretapping directly from governments, as well as third-party attacks on the infrastructure in place to support that monitoring.
>If you don't want end-to-end messages made available to others, set your notifications to only show that you have a message, not what it contains or who its from.
This incorrect on two counts:
1. As per what you wrote immediately before the quoted text, the issue was that the OS keeps track of notifications locally. Google/Apple's notification servers have nothing to do with this
2. It's entirely possible to still have end-to-end messaging even if you're forced to send notifications through Google/Apple's servers, by encrypting data in the notification, or not including message data at all. Indeed that's what signal does. Apple or Google's never sees your message in cleartext.
You are correct, but you omitted one complication: Clients trust Google's and Apple's servers to faithfully exchange the participants' public keys.
Apps (such as Signal) that care about end-to-end encryption do their own key management. So, Apple / Google servers only ever see ciphertext, and don't have access to the key material that's used for the encryption.
Afaik, e2e messengers don't include ciphertext with push notifications. It's an empty push to wake the client. Then the client contacts the origin to fetch the ciphertext.
Sending public keys through the notification system is an unnecessary complication.
... and hold participants' private keys truly private, which you cannot verify without a rooted phone.
Which clients?
Isn’t that what Contact Key Verification solves? Or do I misunderstand how that works?
Both Apple and Google offer the ability for your app to intercept and modify messages before being displayed. Use that to send encrypted messages and decrypt them there, using your own code on the user’s device.
That framing Makes it sound like the app developer has to do something active to keep message cleartext out of notifications. That's not how it is on Android.
A Firebase Cloud Messaging push notification contains what the app developer's server puts in it. That could include the message body or it could just be an instruction to the app to poll the server for new messages. It has nothing to do with the notification that's displayd on an Android device. Those are entirely local.
An app that cares about privacy wouldn't send anything more than a poll instruction over FCM.
In fact this is what both iMessage and Signal (and maybe Whatsapp too but I can’t tell from a quick google) do.
You are right in that it is Google’s and Apple’s OS notification api, and we do give them the plaintext messages.
Seems like you should use an app like Signal for anything sensitive at all so you don't have to worry about megacorp ecosystems as much.
Nope, Signal messages were stored in the phones notification DB even after the app was deleted
https://www.404media.co/fbi-extracts-suspects-deleted-signal...
As mingus88 said, this story is literally in response to Apple leaking messages sent through Signal. Doesn't matter if the message is securely transmitted if the operating system then keeps it lying around in plain text in a cache.
From the linked article:
> The independent news outlet reported that the FBI had been able to extract deleted Signal messages from someone’s iPhone using forensic tools, due to the fact that the content of the messages had been displayed in a notification and then stored inside a phone’s database — even after the messages were deleted inside Signal.
You can easily configure Signal not to show the message contents if you want, though.
The original comment mentions this but gives the wrong reasoning. The APNs are encrypted either way, but this setting prevents Signal from decrypting them client-side and letting the notification cache store it. Yeah this is more secure because it means not trusting Apple to do their job right with local storage, but it's also kind of a reasonable thing to trust.
This is also an oversimplification. If I understand the issue correctly, the notification with the message contents was what was cashed locally and then accessed. This same vulnerability would exist with Signal if you had the notifications configured to display the full message contents. In this case, it has nothing to do with either Apple or Signal.
The "bug" discussed in the article is only part of the problem.
The main problem, which is notifications text is stored on a DB in the phone outside of signal, is not addressed. To avoid that you have to change your settings.
In this case, the defendant had deleted the signal app completely, and that likely internally marks those app's notifications for deletion from the DB, so the bug fixed here is that they were not removing notifications from the local database when the app that generated them was removed, now they do.
They classify this as "loggging issue" so it sounds like notifications were not actually in the database itself but ended up in some log.You're speculating. "Marked for deletion" could mean after you dismiss it, not just after you delete the whole app.
SQLite WAL?
Oh, I was originally confused about this because I had thought the push notifications were end-to-end encrypted, so they couldn't be cached in readable form by the push notification service, and only decrypted by the app on device upon receiving the notification. But it seems like after the notification was decrypted by the app and shown to the user using OS APIs, the notification text was was then stored by the OS in some kind of notification history DB locally on the device?
In privacy circles, this was always known, as Google/Apple often sends notification content to their servers (which means that it bypass the App realm).
Some people talking about it (different but in the same scope of issue): https://blog.davidlibeau.fr/push-notifications-are-a-privacy...
I expect that Signal encrypts the notification data prior to sending it to Apple, then decrypts it on-device using a Notification Service Extension – this is a common pattern to avoid trusting Apple with any sensitive data.
That would mean Apple stored the cleartext on-device after decryption.
Signal doesn’t provide anything in the message other than… “there are pending messages.” Signal wakes up, fetches them, then generates notifications on the phone itself.
in the case reported the content did not leave the device. feds retreived them directly from the phone.
+ Messengers like Snapchat and WhatsApp;
despite "end-to-end" encryption (for WhatsApp) they are sending copy of some messages based on keywords to authorities, PRISM-like.
Officially to protect kids, but who knows what is in this keywords list.
Note that Signal offers the option to use generic “You’ve received messages” notifications - it’s good practice in general.
So does every app, go to iOS settings > notifications shows previews > never.
Most likely changes the preview on the client-side, but the message is still full on the server-side
Is setting it from Signal directly more trustworthy?
Or maybe it’s impossible for iOS to store the preview content if it never showed in the first place, but not sure if it’s even documented.
I wish it can be disabled for particular apps and not an all or nothing situation.
Can be!
Settings > Apps > choose an app > Lock Screen Appearance: Show Previews - Never
That setting is available for each individual app.
It's not new that push notifications should be presumed to be insecure, with their content passing through - and probably persisted - outside the app sandbox and anything in control of in-app encryption.
Apple should have fixed this long ago (not that you can trust a closed system), but Signal should also have strong guardrails & warnings around allowing message content in push notifications.
This makes me wonder: Cellebrite makes tools for law enforcement to break into iPhones, likely exploiting weaknesses/vulnerabilities. Does Apple buy Cellebrite’s tools and reverse engineer them? Or would they not have a way of acquiring them legally?
I bet Apple has access to Mythos now.
Not saying they should use it to reverse engineer hacking tools.
Just saying they have access to Mythos now.
Thankfully Apple backported the fix the iOS 18 as well.
Not only that, but iOS 18.7.8 actually seems to be available to devices capable of running iOS 26 without any workarounds, unlike 18.7.3 through .6. It makes me wonder if those intermediate releases really were supposed to be available but weren't due to some issue on the distribution side that no one bothered to fix.
Very serious vulns were being exploited in the wild, I think that's what forced their hand. I don't think Apple ever had a discrepancy like the one with iOS 18.7.3 through .6 being held back.
For those on iOS 18, beware that the update to iOS 18.7.8 will toggle Automatic Updates back on. Make sure to switch it back off so you don't wake up to a nasty surprise when iOS 26 is non-consensually forced onto your iPhone.
I think that was another attempt by Apple to push users to iOS 26, but after seeing how many people with compatible devices refuse to upgrade, they finally caved in and provided an update.
They caved, but they're still pulling out new tactics to trick users into installing iOS 26.
The new iOS 18 update will _also_ toggle Automatic Updates back on. I had it happen just now on my 13 Mini against my will. I had to go back into settings and very carefully navigate to disable automatic updates.
There seems to have been a change of mind, maybe also due to the severity of the exploits. The non-availability of security updates for models that are upgradable to a newer major version has been Apple's practice for many years now.
The way major upgrades are presented in the Settings UI makes it clear that users installing these security updates while not upgrading to a newer major version do so very intentionally. So Apple is now supporting these users deliberately.
Heads up. They have released an iOS 18 update (good!) but, and please bear the caps:
UPDATING IOS WILL ENABLE AUTOMATIC UPDATES TO IOS 26.
(Bad!) This is a new shady tactic they're using trying to get iOS 18 users to install iOS 26.
Avoid iOS 26 at all costs. I was forced to update to it because I needed to factory reset my phone, and it's super buggy. I'm not even one of those people harping on the Liquid Glass design decisions, those are w/e, the problem is just that the phone routinely freaks out doing basic tasks like trying to open the camera app or close the keyboard. They should roll it back.
This was already the case for 18.7.7. However, after turning automatic updates off in 18.7.7, after updating to 18.7.8 it remained off (reproducibly on several devices I updated). Maybe there is a one-time flag that is set so that after turning off automatic updates after having been turned on automatically, they aren't automatically turned on again on subsequent updates.
Thanks for the warning!
Cat and Mouse, good. This is the adversarial setup that results in a better outcome for all.
It is completely unclear from this article whether this means Apple does no longer cache dismissed notifications somewhere.
I wonder if the same flaw exists on Android/GrapheneOS.
bug or backdoor?
"Never attribute to malice that which is adequately explained by stupidity."