Severity: low · Type: tech-debt · Confidence: medium
Location:src/lotus/lotusWidget.ts:24-42
Problem
lotusParam memoizes cachedParams in a module-level variable on first call and never invalidates it. useTheme's useLayoutEffect (which calls lotusFlag) re-runs on every requestedTheme change (i.e., every host ThemeChange action), but it will keep returning whatever lotusTransparent/lotusTheme value was present in location.hash/search at the very first call, even if EC's HashRouter has since rewritten location.hash for navigation (lobby → in-call) in a way that drops or reorders the query portion. This wasn't verified to actually lose the flag in this fork's router config (the params are seeded before mount in the observed flow), but the caching pattern is a latent staleness trap if that assumption ever changes.
How to trigger
Would require a case where the hash's query string is rebuilt without carrying the original lotusTransparent/lotusTheme params forward during in-iframe navigation.
Suggested fix
Re-derive from window.location on each call (params are lightweight to parse) or invalidate the cache on popstate/hashchange, so a defensive fix costs little and removes the latent risk.
Filed from the September 2026 audit (branch lotus).
**Severity:** low · **Type:** tech-debt · **Confidence:** medium
**Location:** `src/lotus/lotusWidget.ts:24-42`
### Problem
`lotusParam` memoizes `cachedParams` in a module-level variable on first call and never invalidates it. `useTheme`'s `useLayoutEffect` (which calls `lotusFlag`) re-runs on every `requestedTheme` change (i.e., every host `ThemeChange` action), but it will keep returning whatever `lotusTransparent`/`lotusTheme` value was present in `location.hash`/`search` at the very first call, even if EC's `HashRouter` has since rewritten `location.hash` for navigation (lobby → in-call) in a way that drops or reorders the query portion. This wasn't verified to actually lose the flag in this fork's router config (the params are seeded before mount in the observed flow), but the caching pattern is a latent staleness trap if that assumption ever changes.
### How to trigger
Would require a case where the hash's query string is rebuilt without carrying the original `lotusTransparent`/`lotusTheme` params forward during in-iframe navigation.
### Suggested fix
Re-derive from `window.location` on each call (params are lightweight to parse) or invalidate the cache on `popstate`/`hashchange`, so a defensive fix costs little and removes the latent risk.
---
---
_Filed from the September 2026 audit (branch `lotus`)._
jared
added this to the EC fork audit 2026-09 · Medium & Low milestone 2026-09-12 02:13:15 -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: low · Type: tech-debt · Confidence: medium
Location:
src/lotus/lotusWidget.ts:24-42Problem
lotusParammemoizescachedParamsin a module-level variable on first call and never invalidates it.useTheme'suseLayoutEffect(which callslotusFlag) re-runs on everyrequestedThemechange (i.e., every hostThemeChangeaction), but it will keep returning whateverlotusTransparent/lotusThemevalue was present inlocation.hash/searchat the very first call, even if EC'sHashRouterhas since rewrittenlocation.hashfor navigation (lobby → in-call) in a way that drops or reorders the query portion. This wasn't verified to actually lose the flag in this fork's router config (the params are seeded before mount in the observed flow), but the caching pattern is a latent staleness trap if that assumption ever changes.How to trigger
Would require a case where the hash's query string is rebuilt without carrying the original
lotusTransparent/lotusThemeparams forward during in-iframe navigation.Suggested fix
Re-derive from
window.locationon each call (params are lightweight to parse) or invalidate the cache onpopstate/hashchange, so a defensive fix costs little and removes the latent risk.Filed from the September 2026 audit (branch
lotus).