CVE-2026-55491 is a stored XSS in BigBlueButton's screenshare playback handler. A user enters a malicious payload in a meeting name, and that payload executes in the browser of anyone who later views the recording. This is not a live-session attack — it detonates asynchronously, often days or weeks after the initial meeting, when an instructor or administrator reviews the recording. The attacker needs no privileges beyond creating a meeting; the victim inherits the trust context of the reviewer, which in an educational platform typically means elevated permissions.
The vulnerability almost certainly required a 'raw' helper or equivalent to disable Rails' default ERB escaping. The screenshare playback pipeline developed semi-independently from the main presentation playback — it uses WebRTC and separate storage — and this organizational separation created a security blind spot. The meeting name crossed from the meeting creation interface into the recording pipeline and then into a playback template that hadn't been built from secure primitives. The developers who wrote that template were working on playback rendering, not thinking about the injection path from meeting creation.
The detection problem is significant. Security monitoring focuses on live sessions, not the asynchronous playback infrastructure where XSS payloads are delivered much later to a different audience. The temporal asymmetry — attacker plants payload in one session, detonates against an unrelated viewer — creates a blast radius that extends well beyond the meeting participants.
For defenders: audit your BigBlueButton installation for the 3.0.29 patch or later. More importantly, examine whether the fix introduced centralized escaping for all user-controlled metadata in playback templates — or whether it was a localized patch to one file. Check other metadata fields in the screenshare pipeline (timestamps, participant counts, extracted slide titles) for the same class of flaw. If your organization is running an older version, assume the meeting-name field in any existing recordings contains dormant payloads.
The deeper question is structural: does BigBlueButton now have enforced template-layer escaping that makes this class of error impossible going forward — or did someone simply remove a 'raw' call and close the ticket? The version control history of the fix commit will tell you whether this is actually fixed or just patched for now.