BigBlueButton CVE-2026-46355

The attacker must be an authenticated participant in an active BigBlueButton meeting, establishing the low-privilege foothold (PR:L per CVSS vector) required to call the API. The target participant must have an active session in the same meeting at the time of the request - the supplied existingUserID must resolve to a currently-active session or the post-patch null-check would reject it. The /bigbluebutton/api/handleJoinExistingUser endpoint must be reachable over the network, which is standard for any internet-facing BigBlueButton deployment. Exploitation is bounded to the meeting the attacker has joined; cross-meeting session hijacking is not indicated by the vulnerability description or CVSS scope (S:U). The need to know a valid existingUserID of an active participant limits opportunistic mass exploitation, though this value may be obtainable from meeting participant listing APIs or by monitoring API traffic within the meeting.

The provided CVSS 7.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N) accurately reflects the attack profile: network-reachable, low complexity, requiring low privilege (meeting participant), with high integrity impact due to full session impersonation and limited confidentiality exposure. No EPSS score was provided in the input data, so exploitation probability cannot be quantified; this gap should be tracked. No CISA KEV listing indicates active exploitation has not been confirmed at time of analysis. The PR:L requirement is the primary real-world risk governor: an attacker must first join the target meeting, which provides a natural barrier against fully anonymous mass exploitation. However, once inside a meeting, the AC:L rating reflects that exploitation requires only a valid existingUserID, which may be obtainable through meeting participant list APIs or by observing network traffic. The S:U (unchanged scope) rating correctly bounds the impact to the meeting context - cross-meeting or system-level compromise is not indicated. Overall, this is a real priority for organizations hosting sensitive meetings on BigBlueButton, with the risk heightened in deployments where meeting roles carry significant trust (e.g., moderators controlling recording or student assessments).

An attacker who has legitimately joined a BigBlueButton meeting as a low-privilege attendee enumerates the existingUserID of the meeting moderator through observable meeting metadata or API responses. The attacker sends a crafted HTTP request to /bigbluebutton/api/handleJoinExistingUser?existingUserID=<moderator_id> and receives the moderator's active session, gaining the ability to act as the moderator - controlling recording, muting participants, or accessing privileged meeting features. No public exploit code has been identified, but the low attack complexity and straightforward HTTP call suggest this could be trivially scripted by any meeting participant.