Severity: high · Type: security · Confidence: high
Location:src/app/features/room/RoomInput.tsx:794-848 (handleGifSelect, upload at 824-837)
Problem
Every other composer upload path honours room encryption — file attachments (handleFiles, line 339), voice messages (line 307) — but handleGifSelect fetches the Giphy blob and calls mx.uploadContent(...) then mx.sendMessage(..., {url: mxcUrl}) with no encryptFile and no hasEncryptionStateEvent() check. In an encrypted room the GIF itself is stored and served unencrypted (the event body is encrypted, but the mxc content is not), so the homeserver — and, on servers without authenticated media, anyone with the mxc URI — can see what was sent.
How to trigger
In an encrypted room, open the GIF picker and send any GIF; the resulting m.image carries a plain url instead of an encrypted file block.
Suggested fix
Mirror the voice-message branch: when the room is encrypted, encryptFile(blob) → upload the ciphertext → send file: {...encInfo, url} instead of url.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** high · **Type:** security · **Confidence:** high
**Location:** `src/app/features/room/RoomInput.tsx:794-848` (`handleGifSelect`, upload at 824-837)
### Problem
Every other composer upload path honours room encryption — file attachments (`handleFiles`, line 339), voice messages (line 307) — but `handleGifSelect` fetches the Giphy blob and calls `mx.uploadContent(...)` then `mx.sendMessage(..., {url: mxcUrl})` with no `encryptFile` and no `hasEncryptionStateEvent()` check. In an encrypted room the GIF itself is stored and served unencrypted (the event body is encrypted, but the mxc content is not), so the homeserver — and, on servers without authenticated media, anyone with the mxc URI — can see what was sent.
### How to trigger
In an encrypted room, open the GIF picker and send any GIF; the resulting `m.image` carries a plain `url` instead of an encrypted `file` block.
### Suggested fix
Mirror the voice-message branch: when the room is encrypted, `encryptFile(blob)` → upload the ciphertext → send `file: {...encInfo, url}` instead of `url`.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · P0 security & data loss milestone 2026-09-12 01:50:49 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Severity: high · Type: security · Confidence: high
Location:
src/app/features/room/RoomInput.tsx:794-848(handleGifSelect, upload at 824-837)Problem
Every other composer upload path honours room encryption — file attachments (
handleFiles, line 339), voice messages (line 307) — buthandleGifSelectfetches the Giphy blob and callsmx.uploadContent(...)thenmx.sendMessage(..., {url: mxcUrl})with noencryptFileand nohasEncryptionStateEvent()check. In an encrypted room the GIF itself is stored and served unencrypted (the event body is encrypted, but the mxc content is not), so the homeserver — and, on servers without authenticated media, anyone with the mxc URI — can see what was sent.How to trigger
In an encrypted room, open the GIF picker and send any GIF; the resulting
m.imagecarries a plainurlinstead of an encryptedfileblock.Suggested fix
Mirror the voice-message branch: when the room is encrypted,
encryptFile(blob)→ upload the ciphertext → sendfile: {...encInfo, url}instead ofurl.Filed from the September 2026 client audit (branch
lotus@4bea4895).