Severity: medium · Type: security · Confidence: high
Location:src/app/plugins/call/CallEmbed.ts:225-259, contrast src/app/features/room/widgets/widgetUtils.ts:34-41 and src/app/features/room/widgets/RoomWidgetView.tsx:38-49
Problem
the bundled Element Call widget is loaded from window.location.origin
(/public/element-call/index.html) into an iframe carrying sandbox="… allow-scripts allow-same-origin …". For a same-origin document those two tokens together
cancel the sandbox entirely: the frame can reach parent.document, register service-worker messages,
and read localStorage — including cinny_session_v1 / cinny_access_token. The widget code path
right next door (RoomWidgetView) explicitly refuses to render a same-origin widget for exactly this
reason, so the call embed is the one place the stated policy is inverted. EC is first-party bundled
code, so this is defence-in-depth rather than an active hole — but EC renders remote-controlled call
and member data, and any DOM-injection bug there becomes full session compromise.
How to trigger
join a call; in devtools evaluate document.querySelector('iframe[title="Call Embed"]').contentWindow.localStorage.getItem('cinny_session_v1') — it returns the access token.
Suggested fix
serve the EC bundle from a distinct origin (a subdomain or a blob:/data:-less
separate host) so allow-same-origin means the frame's own origin, or drop allow-same-origin and
give EC the storage it needs over the widget postMessage transport.
Filed from the September 2026 client audit (branch lotus @ 4bea4895).
**Severity:** medium · **Type:** security · **Confidence:** high
**Location:** `src/app/plugins/call/CallEmbed.ts:225-259`, contrast `src/app/features/room/widgets/widgetUtils.ts:34-41` and `src/app/features/room/widgets/RoomWidgetView.tsx:38-49`
### Problem
the bundled Element Call widget is loaded from `window.location.origin`
(`/public/element-call/index.html`) into an iframe carrying
`sandbox="… allow-scripts allow-same-origin …"`. For a same-origin document those two tokens together
cancel the sandbox entirely: the frame can reach `parent.document`, register service-worker messages,
and read `localStorage` — including `cinny_session_v1` / `cinny_access_token`. The widget code path
right next door (`RoomWidgetView`) explicitly *refuses* to render a same-origin widget for exactly this
reason, so the call embed is the one place the stated policy is inverted. EC is first-party bundled
code, so this is defence-in-depth rather than an active hole — but EC renders remote-controlled call
and member data, and any DOM-injection bug there becomes full session compromise.
### How to trigger
join a call; in devtools evaluate `document.querySelector('iframe[title="Call Embed"]').contentWindow.localStorage.getItem('cinny_session_v1')` — it returns the access token.
### Suggested fix
serve the EC bundle from a distinct origin (a subdomain or a `blob:`/`data:`-less
separate host) so `allow-same-origin` means the frame's *own* origin, or drop `allow-same-origin` and
give EC the storage it needs over the widget postMessage transport.
---
_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:10 -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/plugins/call/CallEmbed.ts:225-259, contrastsrc/app/features/room/widgets/widgetUtils.ts:34-41andsrc/app/features/room/widgets/RoomWidgetView.tsx:38-49Problem
the bundled Element Call widget is loaded from
window.location.origin(
/public/element-call/index.html) into an iframe carryingsandbox="… allow-scripts allow-same-origin …". For a same-origin document those two tokens togethercancel the sandbox entirely: the frame can reach
parent.document, register service-worker messages,and read
localStorage— includingcinny_session_v1/cinny_access_token. The widget code pathright next door (
RoomWidgetView) explicitly refuses to render a same-origin widget for exactly thisreason, so the call embed is the one place the stated policy is inverted. EC is first-party bundled
code, so this is defence-in-depth rather than an active hole — but EC renders remote-controlled call
and member data, and any DOM-injection bug there becomes full session compromise.
How to trigger
join a call; in devtools evaluate
document.querySelector('iframe[title="Call Embed"]').contentWindow.localStorage.getItem('cinny_session_v1')— it returns the access token.Suggested fix
serve the EC bundle from a distinct origin (a subdomain or a
blob:/data:-lessseparate host) so
allow-same-originmeans the frame's own origin, or dropallow-same-originandgive EC the storage it needs over the widget postMessage transport.
Filed from the September 2026 client audit (branch
lotus@4bea4895).