LOTUS_TODO.md:168 notes drafts as persisted PII, but the behaviour is worse than "residue
on a shared device". Draft keys are draft-msg-<roomId> with no user scoping, and clearPlaintextCaches() deliberately skips them on both logout paths. useHydrateMsgDrafts then runs
on the next boot for whoever logs in, scans all draft-msg-* keys and pushes them into the draft
atoms; RoomInput restores the same content into the live composer. So after user A logs out and user
B logs in on the same browser, user B sees A's unsent decrypted text pre-filled in the composer of any
shared room, with a draft indicator in the room nav, and can send it under B's identity.
How to trigger
as user A, type (do not send) a message in a room; log out; log in as user B who is also in
that room; open it — A's draft is in the composer.
Suggested fix
key drafts per user (draft-msg-<userId>-<roomId>) and/or wipe draft-msg-* in clearPlaintextCaches(); at minimum refuse to hydrate drafts written by a different userId.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** security · **Confidence:** high
**Location:** `src/app/state/plaintextCaches.ts:28-30`, `src/client/initMatrix.ts:129-133`, `src/app/hooks/useHydrateMsgDrafts.ts:19-44`, `src/app/features/room/RoomInput.tsx:199,393-425`
### Problem
`LOTUS_TODO.md:168` notes drafts as persisted PII, but the behaviour is worse than "residue
on a shared device". Draft keys are `draft-msg-<roomId>` with **no user scoping**, and
`clearPlaintextCaches()` deliberately skips them on both logout paths. `useHydrateMsgDrafts` then runs
on the next boot for whoever logs in, scans all `draft-msg-*` keys and pushes them into the draft
atoms; `RoomInput` restores the same content into the live composer. So after user A logs out and user
B logs in on the same browser, user B sees A's unsent decrypted text pre-filled in the composer of any
shared room, with a draft indicator in the room nav, and can send it under B's identity.
### How to trigger
as user A, type (do not send) a message in a room; log out; log in as user B who is also in
that room; open it — A's draft is in the composer.
### Suggested fix
key drafts per user (`draft-msg-<userId>-<roomId>`) and/or wipe `draft-msg-*` in
`clearPlaintextCaches()`; at minimum refuse to hydrate drafts written by a different `userId`.
---
_Filed from the September 2026 client audit (branch `lotus` @ 4bea4895)._
jared
added this to the Audit 2026-09 · Medium & Low milestone 2026-09-12 01:51:09 -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: medium · Type: security · Confidence: high
Location:
src/app/state/plaintextCaches.ts:28-30,src/client/initMatrix.ts:129-133,src/app/hooks/useHydrateMsgDrafts.ts:19-44,src/app/features/room/RoomInput.tsx:199,393-425Problem
LOTUS_TODO.md:168notes drafts as persisted PII, but the behaviour is worse than "residueon a shared device". Draft keys are
draft-msg-<roomId>with no user scoping, andclearPlaintextCaches()deliberately skips them on both logout paths.useHydrateMsgDraftsthen runson the next boot for whoever logs in, scans all
draft-msg-*keys and pushes them into the draftatoms;
RoomInputrestores the same content into the live composer. So after user A logs out and userB logs in on the same browser, user B sees A's unsent decrypted text pre-filled in the composer of any
shared room, with a draft indicator in the room nav, and can send it under B's identity.
How to trigger
as user A, type (do not send) a message in a room; log out; log in as user B who is also in
that room; open it — A's draft is in the composer.
Suggested fix
key drafts per user (
draft-msg-<userId>-<roomId>) and/or wipedraft-msg-*inclearPlaintextCaches(); at minimum refuse to hydrate drafts written by a differentuserId.Filed from the September 2026 client audit (branch
lotus@4bea4895).