Signal – Deleted, but Not Forgotten

HotGarbage1 pts0 comments

Signal - Deleted, but not forgotten<br>The latest version of this advisory is available at:<br>https://sintonen.fi/advisories/signal-deleted-but-not-forgotten.txt

Description

Signal client uses SQLcipher database to store conversation messages. Since SQLcipher<br>is essentially SQLite with encryption, it inherits SQLite features.

To update the database, SQLite (and consequently SQLcipher) uses Write-Ahead Logging.<br>All transactions are written to a Write-Ahead Log file, which is then merged to the<br>main database file when a certain number of pages are written to the log file, the<br>database is manually checkpointed, or the database file is reopened.

This results in an unexpected situation when messages are deleted in Signal, either<br>manually or by a timed deletion. The deletions from the database are recorded to the<br>Write-Ahead Log file, but they are not actually deleted from the database file until<br>the Write-Ahead Log is committed back to the main database.

By default, the Write-Ahead Log has a threshold size of 1000 pages. Depending on how<br>busy your Signal app is, this transaction limit could take several days to reach. This<br>means that the messages deleted in Signal will linger on disk far longer than expected.<br>The database file with the supposedly deleted messages can easily end up being backed<br>up to Time Machine backups, adding unexpected data persistence.

Impact

Many people and organizations are using disappearing messages to ensure that no trace<br>of messages remains after a certain timeout. It is also fair to expect a message to<br>disappear from disk as soon as it disappears from the UI.

Due to this flaw, the messages may be recoverable from disk for far longer than<br>expected, up to multiple days, or even weeks for low-volume messaging.

Since Signal message database is included in macOS Time Machine backups, the<br>supposedly deleted messages can remain recoverable from such backups for years.

The message database file is encrypted. This lessens the impact of this vulnerability<br>significantly. However, this vulnerability may become significant if mobile device<br>acquisition (or other kind of device forensics) is a threat the Signal user tries to<br>defend against and if disappearing messages are employed in attempt to protect<br>against such recovery.

Restrictions

This vulnerability is mitigated by several factors:

1. The database is encrypted. To extract any deleted messages, the attacker will<br>have to defeat the encryption. This requires capabilities and expertise.

2. Active Signal use will reach the Write-Ahead log page limit fast, leading to<br>merging of log fairly regularly.

3. Signal app restart will commit the Write-Ahead Log, deleting the messages.

Proof-of-Concept

This Proof-of-Concept demonstrates the issue with Signal macOS desktop app:

1. Grab and build https://github.com/fjh658/signal-decryption-tool

2. Utilize signal-decryption-tool to obtain the encryption key with:<br>$ target/release/SignalDecryption -p

3. Send a test message from external account to your Signal. Use some<br>content you can later search for, such as "KENSENTME".

4. Delete the message in your Signal desktop app.

5. Copy the Signal database separating it from the Write-Ahead Log file:<br>$ cp ~/"Library/Application Support/Signal/sql/db.sqlite" .

6. Use sqlcipher to extract the now supposedly deleted message:<br>$ sqlcipher db.sqlite<br>sqlite> PRAGMA key = "x'hexkeyhere'";<br>sqlite> select * from messages where body like '%KENSENTME%';

Recommendations to vendor

Modify Signal application to perform manual commit on message deletion to<br>ensure that delete messages won't stay on disk unexpectedly. The strategy<br>could employ a delay timeout of a short period to avoid excessive write<br>operations on multiple deletions.

On macOS, consider excluding the message database from backups by using<br>com.apple.metadata:com_apple_backup_excludeItem attribute.

End user mitigation

1. After deleting highly sensitive information, restart Signal app to force a<br>Write-Ahead Log commit.

2. With macOS, consider excluding ~/Library/Application Support/Signal/sql from<br>Time Machine backups:

$ sudo tmutil addexclusion -p ~/"Library/Application Support/Signal/sql"

Note: You may be requested to grant Full Disk Access privileges to the<br>Terminal application - if you do so, you can remove the privilege after<br>adding the exclusion.

3. For high security communications, avoid linking your mobile Signal to the<br>desktop Signal client.

Affected Applications<br>- Signal Desktop application is affected (macOS app tested).<br>- Signal Android application is likely affected.<br>- Signal iOS application does not appear to be affected due to custom<br>checkpointing strategy. However, I did not test this is in detail.

Timeline

2025-11-23 discovered the vulnerability.<br>2025-11-23 sent report to security@signal.org - no acknowledgement received.<br>2025-11-25 sent report to NCSC-FI to inform finnish stakeholders.<br>2026-02-27 resent report to security@signal.org asking for acknowledgement of<br>receipt - no...

signal database messages from deleted write

Related Articles