Repository navigation
security(collaboration): WS /ws/sessions/{id}/presence trusts an unauthenticated client-supplied user_id #16455
Description
Activity
- added a commit that references this issue
on Sep 12, 2026 - linked a pull request that will close this issuesecurity(collaboration): authenticate and authorize the session-presence WebSocket (#16455) #16456
on Sep 12, 2026 - added a commit that references this issue
on Sep 12, 2026 - added a commit that references this issue
on Sep 13, 2026 Closure evidence (batch 2c)
Verified against
origin/main(PR #16456, c7c34f3). The issue has no checkboxes, so the Fix section is taken as the criteria. All met.Criterion (from Fix) Evidence user_id: str = Query(...)removedautobot-backend/api/presence_ws.py:62-65signature is(websocket: WebSocket, session_id: str); testpresence_ws_auth_16455_test.py::test_a_spoofed_user_id_query_param_has_no_effect_on_identityauthenticate_websocketruns beforepresence_manager.connectpresence_ws.py:82user_payload = await authenticate_websocket(websocket), before the handler call at:108accept()first, thenclose(code=4001)onNonepresence_ws.py:86-87;_WS_CLOSE_UNAUTHENTICATED= 4001 at:35; teststest_no_token_closes_4001,test_a_bad_token_closes_4001user_idcomes from the verified payloadpresence_ws.py:92user_id = uuid.UUID(str(user_payload["user_id"])); testtest_an_authorized_participant_connects_under_their_real_identityAlso added: a verified non-participant is refused (
:101-105, close 1008;test_a_verified_user_not_on_the_session_is_refused). Whether the frontend caller sends?token=belongs to #16443 and was not checked.- added a commit that references this issue
on Sep 13, 2026
Verdict
WS /ws/sessions/{session_id}/presence(api/presence_ws.py) trusts a client-supplieduser_idquery parameter as the caller's identity, with zero verification. Any caller can join any session's presence channel as any user, see who's genuinely online, and broadcast arbitrary messages to real participants under a spoofed identity.Evidence
api/presence_ws.py:29-32(session_presence'suser_id: str = Query(...))api/presence_ws.py:44(docstring)"passed as query param until WS auth middleware is extended to cover WebSocket handshakes for this path"— but that extension already exists (see next row)auth_middleware.py:1061(authenticate_websocket)?token=<JWT>, returns a verified user dict. Used byapi/live_events.py's/ws/livefor exactly this purpose.presence_ws.pydoesn't call it.initialization/router_registry/feature_routers.py:688-691websocket/presence.py(PresenceManager)Fix
Replace the
user_id: str = Query(...)parameter with a call toauth_middleware.authenticate_websocket(websocket)beforepresence_manager.connect(...), matchingapi/live_events.py's pattern exactly:await websocket.accept()first (project WS rule — clients see a clean close frame, not a handshake 403), thenauthenticate_websocket, thenclose(code=4001)onNone. Deriveuser_idfrom the verified payload, never from client input.Discovered During
Investigating #16443 (wiring in the collaboration UI) — traced
useSessionCollaboration.ts's WebSocket dependency to confirm what backend actually exists, found a complete backend (REST APIapi/collaboration.py+ this WS presence handler) that the frontend never uses, and found this identity gap while reading the WS handler to plan the wiring.