Signal Desktop refuses to auto-download attachments from message requests you haven’t accepted — that’s by design, and it works correctly for the original message.
But it doesn’t check that same “accepted” flag on the edit path.
If an unaccepted sender edits their message afterward — even just changing one character of the caption — Desktop will fetch, decrypt, MAC-validate, and write the original attachment to disk anyway.
You don’t have to accept the request. You don’t have to open the chat.
You don’t have to click anything.
The app just needs to be running and signed in.
What this actually lets an attacker do:
Attacker requirements: be the author of the original message, send a DataMessage plus a later edit of it, within the 48-hour edit window, from an ACI (not a PNI) identity. No prior accept, no system contact, no profile sharing needed.
What still gets force-downloaded via this path: photos, videos, documents, link-preview images (if the body still contains the URL), quote thumbnails (these are always queued once the function runs, regardless of toggle), stickers ≤100 KiB, and contact avatars on non-contact-share messages.
What’s blocked by the function’s own guards: voice notes, view-once messages, contact-share messages, edits past 48 hours, and anything from a PNI-only sender. A message that mixes a voice note with other attachment types still has those other attachments bypass the gate, since only the voice-note-only path is excluded.
Scams & Phishing Phishing emails are baiting your AI assistant