The bug is an ordering/consistency defect in WebPageProxy::setMuted in the UIProcess, the trusted broker that decides whether camera/microphone capture is muted. setMuted receives a requested MediaProducerMutedStateFlags and must reconcile it with the web app’s own desired muted kinds via applyWebAppDesiredMutedKinds(state, m_mutedCaptureKindsDesiredByWebApp) to produce the authoritative newState that is then pushed to the WebContent process(es). In the vulnerable version the reconciliation was performed too late: the function first stored internals().mutedState = state (the raw, un-reconciled request) and first notified every web content process with process.pageMutedStateChanged(pageID, state) using the raw state, and only AFTER those side effects computed newState = applyWebAppDesiredMutedKinds(...). Consequently the UIProcess’s cached muted state and the pageMutedStateChanged notification reflected state rather than the web-app-adjusted newState, while the later async Messages::WebPage::SetMuted used newState — an internal inconsistency. The violated invariant is that all consumers of the page’s muted state (the cached internals().mutedState and every content-process notification) must observe the single authoritative, web-app-reconciled muted state; here two different values were propagated. In practice this meant capture could remain effectively unmuted/active when the reconciled policy should have muted it, allowing a website to access camera/microphone (sensor) data without proper consent — matching the advisory ‘a website may be able to access sensor information without user consent.’

The fix computes newState (via applyWebAppDesiredMutedKinds under ENABLE(MEDIA_STREAM), else newState = state) BEFORE any side effects, stores internals().mutedState = newState, and sends pageMutedStateChanged(pageID, newState), so the cache, the state-changed notification, and the SetMuted message all carry the same reconciled value. The added API test GetUserMediaAfterMuting and the startAudioCapture/startVideoCapture test helpers exercise muting camera and microphone and then re-requesting capture, asserting prompt counts, which validates that muting is applied consistently.

This is a privacy/consent defect, not a memory-safety issue: the patch shows an ordering bug where the UIProcess propagated a stale (un-reconciled) muted state to its cache and to content processes, allowing camera/microphone capture to remain active when it should have been muted. The realistic impact is unauthorized access to sensor (audio/video) data by a website without proper user consent, as stated in the advisory; there is no memory corruption, OOB, or code-execution primitive implied by the diff. The logic resides in the UIProcess but the consequence is that the sandboxed WebContent process (and thus the site) receives capture it should not; no sandbox escape is involved.