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.

▲ firesteelrain an hour ago | parent | next [-]

This tweet seems to imply it’s logs, json, plist and SQLite DB.

Biome — /private/var/mobile/Library/Biome/streams/.../Notification/segments/ — the raw title/body logs

2. BulletinBoard + UserNotificationsCore — /var/mobile/Library/{BulletinBoard,UserNotificationsCore}/.{json,plist} — delivered + dismissed state

3. CoreDuet — /var/mobile/Library/CoreDuet/coreduetdClassD.db — SQLite that re-ingests Biome events

https://x.com/zeroxjf/status/2047081983449178128?s=46

▲ concinds 5 hours ago | parent | prev | next [-]

You're speculating. "Marked for deletion" could mean after you dismiss it, not just after you delete the whole app.

	▲	6thbit 4 hours ago \| parent [-]
		i'll speculate further: it could've been on the dismiss notification code, and when you delete the app the OS dismisses the removed app's notifications, triggering the same code path. in this case as per reporting, defendant removed the app. unclear if they first dismissed them.

▲ twoodfin 5 hours ago | parent | prev | next [-]

SQLite WAL?

▲ saagarjha 4 hours ago | parent | prev [-]

Why do you think they aren't the same thing?