- by x32x01 ||
Signal Desktop is designed to prevent attachments from unknown senders from downloading automatically until you accept their message request. However, a security flaw identified in Signal Desktop 8.30.0 allows an attacker to bypass this protection by editing a previously sent message.
The surprising part? Changing just one character in the message caption can trigger the download of its original attachment.
The recipient doesn't need to accept the conversation, open the chat, or click anything. Signal Desktop only needs to be running and signed in.
The issue occurs because Signal checks whether a conversation has been accepted when processing new messages but fails to apply the same security check when processing message edits.
Key finding: The research identified the flaw through analysis of Signal Desktop's installed production code and 18 targeted tests. According to the researcher's disclosure, Signal accepted the report as a critical-severity issue.
When someone outside your trusted contacts sends a message containing an attachment, Signal Desktop normally prevents that attachment from downloading automatically.
The application checks whether the conversation has been accepted before adding the attachment to its download queue.
This protection is implemented in the
Its core condition is:
The condition requires two things:
As a result, the attachment remains pending rather than being downloaded to the recipient's device.
This protection works correctly when the original message arrives.
The problem begins when the sender edits that message.
When an incoming message contains an edit timestamp, the application routes it directly to the edit-handling system.
The relevant logic in
Because the function returns immediately, the edited message bypasses the normal new-message processing path.
That means it never reaches the attachment protection implemented in
Instead, Signal passes the edit to
For example, it rejects certain unsupported message types and edits that exceed the permitted 48-hour window.
However, these checks do not verify whether the recipient has accepted the conversation.
After passing the validation stage, the handler copies the original message's attachment references into the edited message.
It then executes:
Notice what's missing.
There is no
The function
Consequently, an edited message can trigger an automatic download even while its conversation remains an unaccepted message request.
Importantly, this does not allow the attacker to introduce an entirely new attachment through the edit. The vulnerability re-triggers downloads for attachment references associated with the original message.
The same edit-handling function checks conversation acceptance before sending certain delivery receipts.
Its condition includes:
In other words, Signal remembers to enforce the acceptance requirement for delivery receipts but not for attachment downloads.
The security boundary is enforced inconsistently across two operations within the same function.
The attack requires relatively limited conditions.
Attacker requirements:
The recipient does not need to open the conversation or manually initiate the attachment download.
Some message types are excluded by existing validation rules.
These include:
Message requests are supposed to let recipients decide whether they want to engage with an unknown sender before the application automatically retrieves that sender's attachments.
Bypassing that decision introduces several security concerns.
1. Unrequested attachment downloads
An unknown sender can trigger the retrieval of attachment data without the recipient accepting the conversation.
2. Automatic processing of attacker-controlled content
The affected download pipeline retrieves attachment data, decrypts it, performs integrity validation, and writes the resulting file to local storage.
This creates an additional path through which content supplied by an untrusted sender reaches the recipient's device.
3. Local file creation
Downloaded attachments can be written into Signal Desktop's
The recipient has not explicitly authorized the conversation, yet its attachment data can already exist locally.
4. Potential exposure to future media-processing vulnerabilities
The research also notes that Signal Desktop's main Electron renderer uses the following configuration:
The absence of renderer sandboxing increases the importance of carefully controlling which untrusted content reaches the media-processing pipeline.
However, this distinction is essential:
The reported vulnerability does not demonstrate remote code execution (RCE).
There is no demonstrated memory corruption or arbitrary code execution in the supplied research.
The confirmed issue is an attachment-download authorization bypass. Any potential exploitation through a separate media decoder vulnerability would require additional evidence.
The researcher also extracted and examined the installed Signal Desktop 8.30.0 application's production
Analysis of its minified JavaScript confirmed that the relevant behavior existed in the distributed application.
The production code contained both:
The test environment used simulated database, network, and persistence components rather than conducting live attacks against real accounts.
The test scenario included an ACI sender, a 48 KiB JPEG attachment, and an immediate message edit.
All 18 targeted checks passed.
The tests confirmed three particularly important behaviors:
They should not, however, be confused with evidence of widespread exploitation or a demonstrated remote-code-execution attack.
No malicious attachment or exploit payload is required.
Controlled reproduction steps:
The expected distinction is that the original message does not queue an attachment download, while the subsequent edit causes the attachment-download function to queue a job.
Safety note: Perform this test only with disposable accounts and devices you control. Avoid using personal accounts containing real conversations or sensitive attachments.
It already implements one for newly received messages.
The appropriate fix is to enforce the same authorization rule consistently when processing message edits.
Before
The existing authorization predicate is:
Applying the equivalent condition to the edit-processing path would prevent unaccepted incoming conversations from triggering automatic attachment downloads.
Crucially, rejecting the download should not reject the entire message edit.
Signal should still be able to update the message's text, timestamp, and edit history without retrieving its attachment.
Once the recipient accepts the conversation, the existing message-request acceptance flow can process pending attachments through
This preserves normal application functionality while restoring the intended security boundary.
Users should keep Signal Desktop updated and install security releases as they become available.
Until a fix is independently confirmed for their installed version, users who want to reduce exposure can consider closing Signal Desktop when it is not needed, particularly if they frequently receive unsolicited message requests.
This is a precaution, not a confirmed software-level fix.
Changing attachment auto-download preferences may also reduce exposure to some attachment categories, but should not be treated as a complete workaround because the research identified paths that do not behave identically across attachment types.
Users should also avoid opening unexpected files from unknown senders, even if those files appear inside an ordinary Signal conversation.
The original message respects the recipient's decision not to accept an unknown sender. Editing that same message can bypass the attachment gate and initiate a download anyway.
The reported research confirms the behavior through production-code analysis and targeted testing, without demonstrating remote code execution or live exploitation against real users.
The broader security lesson is straightforward: authorization checks must remain consistent across every operation capable of triggering the same sensitive action.
The surprising part? Changing just one character in the message caption can trigger the download of its original attachment.
The recipient doesn't need to accept the conversation, open the chat, or click anything. Signal Desktop only needs to be running and signed in.
The issue occurs because Signal checks whether a conversation has been accepted when processing new messages but fails to apply the same security check when processing message edits.
Key finding: The research identified the flaw through analysis of Signal Desktop's installed production code and 18 targeted tests. According to the researcher's disclosure, Signal accepted the report as a critical-severity issue.
🔍 How Signal Desktop's Attachment Protection Works
Signal uses message requests to give users control over conversations initiated by unknown senders.When someone outside your trusted contacts sends a message containing an attachment, Signal Desktop normally prevents that attachment from downloading automatically.
The application checks whether the conversation has been accepted before adding the attachment to its download queue.
This protection is implemented in the
handleAttachmentDownloadsForNewMessage function.Its core condition is:
JavaScript:
shouldQueueForDownload =
hasAttachmentDownloads(message.attributes) &&
(conversation.getAccepted() || isOutgoing(message.attributes));- The message contains an attachment that needs downloading.
- The conversation has been accepted, or the message is outgoing.
As a result, the attachment remains pending rather than being downloaded to the recipient's device.
This protection works correctly when the original message arrives.
The problem begins when the sender edits that message.
Where the Signal Desktop Vulnerability Occurs
Signal Desktop processes message edits differently from newly received messages.When an incoming message contains an edit timestamp, the application routes it directly to the edit-handling system.
The relevant logic in
background.ts follows this pattern: JavaScript:
if (data.message.editedMessageTimestamp) {
// ...
drop(Edits.onEdit(editAttributes));
return;
}That means it never reaches the attachment protection implemented in
handleAttachmentDownloadsForNewMessage.Instead, Signal passes the edit to
Edits.onEdit and subsequently to handleEditMessage.The Missing Security Check
The edit handler includes several validation rules.For example, it rejects certain unsupported message types and edits that exceed the permitted 48-hour window.
However, these checks do not verify whether the recipient has accepted the conversation.
After passing the validation stage, the handler copies the original message's attachment references into the edited message.
It then executes:
JavaScript:
const wasUpdated = await queueAttachmentDownloads(mainMessageModel, {
isManualDownload: false,
});There is no
conversation.getAccepted() check before the download operation.The function
queueAttachmentDownloads also lacks that acceptance check, as does the underlying attachment job queue.Consequently, an edited message can trigger an automatic download even while its conversation remains an unaccepted message request.
Importantly, this does not allow the attacker to introduce an entirely new attachment through the edit. The vulnerability re-triggers downloads for attachment references associated with the original message.
Signal Already Checks Acceptance Elsewhere
One detail makes this vulnerability particularly interesting.The same edit-handling function checks conversation acceptance before sending certain delivery receipts.
Its condition includes:
JavaScript:
if (
isIncoming(upgradedEditedMessageData) &&
upgradedEditedMessageData.unidentifiedDeliveryReceived &&
!hasErrors(upgradedEditedMessageData) &&
conversation?.getAccepted()
) {
deliveryReceiptBatcher.add({ messageId: ... });
}The security boundary is enforced inconsistently across two operations within the same function.
⚠️ What Can an Attacker Actually Do?
The vulnerability allows an unknown sender to cause Signal Desktop to download an attachment without the recipient explicitly accepting the message request.The attack requires relatively limited conditions.
Attacker requirements:
- Control the account that sent the original message.
- Send a message containing an attachment.
- Edit that message within the supported 48-hour window.
- Use an ACI identity rather than a PNI-only sender.
- Preserve the original attachment reference.
- Signal Desktop is running and signed in.
- Default automatic attachment download settings are enabled.
- The sender's message request remains unaccepted.
The recipient does not need to open the conversation or manually initiate the attachment download.
Which Attachment Types Are Affected?
The research identified several attachment categories that can reach the download queue through the edit-processing path.| Attachment type | Observed behavior |
|---|---|
| Photos | Can be downloaded |
| Videos | Can be downloaded |
| Documents | Can be downloaded |
| Link preview images | Affected when the message still contains the URL |
| Quote thumbnails | Queued when the affected processing path runs |
| Stickers | Affected within the 100 KiB limit |
| Contact avatars | Affected on eligible non-contact-share messages |
These include:
- View-once messages.
- Contact-share messages.
- Voice-note-only messages.
- Edits older than 48 hours.
- Messages from PNI-only senders.
Why This Security Flaw Matters
The vulnerability breaks an important trust boundary.Message requests are supposed to let recipients decide whether they want to engage with an unknown sender before the application automatically retrieves that sender's attachments.
Bypassing that decision introduces several security concerns.
1. Unrequested attachment downloads
An unknown sender can trigger the retrieval of attachment data without the recipient accepting the conversation.
2. Automatic processing of attacker-controlled content
The affected download pipeline retrieves attachment data, decrypts it, performs integrity validation, and writes the resulting file to local storage.
This creates an additional path through which content supplied by an untrusted sender reaches the recipient's device.
3. Local file creation
Downloaded attachments can be written into Signal Desktop's
attachments.noindex storage directory.The recipient has not explicitly authorized the conversation, yet its attachment data can already exist locally.
4. Potential exposure to future media-processing vulnerabilities
The research also notes that Signal Desktop's main Electron renderer uses the following configuration:
JavaScript:
sandbox: false
contextIsolation: true
nodeIntegration: falseHowever, this distinction is essential:
The reported vulnerability does not demonstrate remote code execution (RCE).
There is no demonstrated memory corruption or arbitrary code execution in the supplied research.
The confirmed issue is an attachment-download authorization bypass. Any potential exploitation through a separate media decoder vulnerability would require additional evidence.
🧪 How Researchers Verified the Vulnerability
The finding was not based exclusively on publicly available GitHub source code.The researcher also extracted and examined the installed Signal Desktop 8.30.0 application's production
app.asar package.Analysis of its minified JavaScript confirmed that the relevant behavior existed in the distributed application.
The production code contained both:
- The correct acceptance check in the new-message attachment processing path.
- The missing acceptance check in the message-edit download path.
The test environment used simulated database, network, and persistence components rather than conducting live attacks against real accounts.
The test scenario included an ACI sender, a 48 KiB JPEG attachment, and an immediate message edit.
All 18 targeted checks passed.
The tests confirmed three particularly important behaviors:
- The original attachment was correctly prevented from downloading while the conversation remained unaccepted.
- Editing that same message caused its attachment download to be queued.
- Delivery-receipt processing continued to respect the conversation acceptance requirement.
They should not, however, be confused with evidence of widespread exploitation or a demonstrated remote-code-execution attack.
How to Reproduce the Issue Safely
Security researchers can examine the behavior using two disposable Signal test accounts under their control.No malicious attachment or exploit payload is required.
Controlled reproduction steps:
- Prepare two test accounts and connect the recipient account to Signal Desktop.
- Ensure the sender is not an accepted contact.
- Send an ordinary image with a caption to the recipient.
- Leave the incoming message request unaccepted.
- Observe that the original attachment is not automatically downloaded.
- Edit the original message from the sender account, changing one character in its caption.
- Keep the original attachment unchanged.
- Observe the recipient's attachment-download behavior without interacting with the message request.
The expected distinction is that the original message does not queue an attachment download, while the subsequent edit causes the attachment-download function to queue a job.
Safety note: Perform this test only with disposable accounts and devices you control. Avoid using personal accounts containing real conversations or sensitive attachments.
🛠️ How Signal Can Fix the Attachment Bypass
The underlying problem is not that Signal lacks an attachment authorization mechanism.It already implements one for newly received messages.
The appropriate fix is to enforce the same authorization rule consistently when processing message edits.
Before
handleEditMessage queues an automatic attachment download, it should verify whether the conversation is accepted or the message is outgoing.The existing authorization predicate is:
JavaScript:
conversation.getAccepted() || isOutgoing(message.attributes)Crucially, rejecting the download should not reject the entire message edit.
Signal should still be able to update the message's text, timestamp, and edit history without retrieving its attachment.
Once the recipient accepts the conversation, the existing message-request acceptance flow can process pending attachments through
applyMessageRequestResponse and handleReadAndDownloadAttachments.This preserves normal application functionality while restoring the intended security boundary.
What Signal Desktop Users Should Do
The reported behavior concerns Signal Desktop 8.30.0, the version examined in the supplied research.Users should keep Signal Desktop updated and install security releases as they become available.
Until a fix is independently confirmed for their installed version, users who want to reduce exposure can consider closing Signal Desktop when it is not needed, particularly if they frequently receive unsolicited message requests.
This is a precaution, not a confirmed software-level fix.
Changing attachment auto-download preferences may also reduce exposure to some attachment categories, but should not be treated as a complete workaround because the research identified paths that do not behave identically across attachment types.
Users should also avoid opening unexpected files from unknown senders, even if those files appear inside an ordinary Signal conversation.
Frequently Asked Questions
------------------Does this Signal Desktop vulnerability require clicking an attachment?
No. The reported bypass can trigger an automatic attachment download without the recipient opening the conversation, accepting the message request, or clicking the attachment.Can an attacker replace an attachment by editing the message?
The demonstrated behavior involves re-triggering the download of existing attachment references. It does not establish that an attacker can add an entirely new attachment through the edit.Does this vulnerability allow remote code execution?
No remote code execution was demonstrated. The confirmed finding concerns bypassing the attachment-download authorization check.Is Signal's end-to-end encryption broken?
No. The reported flaw concerns client-side attachment handling and conversation acceptance. It does not demonstrate a compromise of Signal's end-to-end encryption.Does this affect Signal on Android or iOS?
The supplied research specifically examines Signal Desktop 8.30.0. It does not establish that the same vulnerability exists in Signal's mobile applications.Has Signal acknowledged the issue?
According to the researcher's disclosure note, the issue was reported to Signal and accepted as critical severity. The supplied research does not establish a public advisory identifier, remediation version, or release date.Final Thoughts
This Signal Desktop vulnerability illustrates how a small inconsistency between two message-processing paths can undermine an otherwise correctly implemented security control.The original message respects the recipient's decision not to accept an unknown sender. Editing that same message can bypass the attachment gate and initiate a download anyway.
The reported research confirms the behavior through production-code analysis and targeted testing, without demonstrating remote code execution or live exploitation against real users.
The broader security lesson is straightforward: authorization checks must remain consistent across every operation capable of triggering the same sensitive action.