CVE-2025-49517

Overview

Moodle is an open source learning management system written in PHP. Schools, universities, and companies use it to run online courses. IOMAD is a multi-tenant distribution of Moodle that lets one installation serve several companies or organizations; it is built on Moodle core and shares the affected code. The BigBlueButton activity module (mod_bigbluebuttonbn) connects Moodle to a BigBlueButton web conferencing server, so teachers can run live sessions from a course and participants can play back the recorded sessions afterwards.

An Improper Access Control vulnerability (CVE-2025-49517) has been identified in the BigBlueButton activity module of Moodle and IOMAD, which allows a logged-in user who can open one BigBlueButton activity to play recordings that belong to other activities, courses, or groups by changing the recording ID in a playback URL. Moodle tracks this issue as MSA-25-0035 (MDL-84706).

Per MITRE CWE-284: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

This issue affects all versions of Moodle before 4.1.19, versions 4.2.0 through 4.4.8, versions 4.5.0 through 4.5.4, and version 5.0.0, including End-of-Life release lines such as Moodle 4.3. IOMAD releases built on these Moodle versions contain the same code and are affected as well.

Details

Module Info

• Product: Moodle, IOMAD
• Affected packages: moodle/moodle (mod/bigbluebuttonbn)
• Affected versions: <4.1.19, >=4.2.0 <4.4.9, >=4.5.0 <4.5.5, >=5.0.0 <5.0.1
• GitHub repository: https://github.com/moodle/moodle (Moodle), https://github.com/iomad/iomad (IOMAD)
• Published packages: https://packagist.org/packages/moodle/moodle
• Package manager: Composer
• Fixed in:
  • OSS Moodle 4.1.19, 4.4.9, 4.5.5, 5.0.1
  • NES for Moodle v4.3.13
  • NES for IOMAD v4.3.4

Vulnerability Info

This High-severity vulnerability is found in the moodle/moodle package in all versions before 4.1.19, 4.2.0 through 4.4.8, 4.5.0 through 4.5.4, and 5.0.0 of Moodle, and in IOMAD releases built on those versions. Moodle rates it Serious.

Playback links in a BigBlueButton activity point to mod/bigbluebuttonbn/bbb_view.php with action=play, the activity (bn), and the local recording ID (rid). The script loads the activity from id or bn and calls require_login() for that activity's course and course module. The play branch then loaded the recording by its ID alone and redirected the browser to its playback URL on the BigBlueButton server:

    case 'play':
        $recording = recording::get_record(['id' => $rid]);
        if ($href = $recording->get_remote_playback_url($rtype)) {
            logger::log_recording_played_event($instance, $rid);
            redirect(urldecode($href));
        } else {
            notification::add(get_string('recordingurlnotfound', 'mod_bigbluebuttonbn'), notification::ERROR);
            redirect($instance->get_view_url());
        }

Nothing tied the recording to the activity the user had just been authorized for. recording::get_record() reads any row in the bigbluebuttonbn_recordings table, so the activity in the URL only had to be one the user could open, while rid could name any recording on the site. The group filtering that the activity applies to its own recording list was skipped as well. Recording IDs are sequential database IDs, so they are easy to enumerate.

Any logged-in user who can open at least one BigBlueButton activity, such as a student enrolled in a course that contains one, can therefore play recordings from other courses, from other groups in a separate-groups activity, and from activities they have no access to. Recorded sessions can include lectures, discussions, shared slides, and the voices and video of other participants. Sites that do not use the BigBlueButton module are not exposed.

The fix looks the recording up in the list that the activity itself returns, which applies the activity's group restrictions, and refuses any ID that is not in that list:

    case 'play':
        $recordings = $instance->get_recordings();
        if (!isset($recordings[$rid])) {
            notification::add(get_string('recordingnotfound', 'mod_bigbluebuttonbn'), notification::ERROR);
            redirect($instance->get_view_url());
        }

The same change adds require_sesskey() to bbb_view.php and adds the session key to the join, logout, and playback URLs that Moodle generates, so another site can no longer trigger these actions on a user's behalf.

Mitigation

Moodle publishes security fixes only for its supported release lines. Earlier release lines, including Moodle 4.3 and the IOMAD releases built on it, are End-of-Life and will not receive any public updates to address this issue.

Until an upgrade is possible, sites that do not need BigBlueButton can disable the module under Site administration > Plugins > Activity modules > Manage activities.

Users of the affected components should apply one of the following mitigations:

• Upgrade to Moodle 4.1.19, 4.4.9, 4.5.5, 5.0.1, or later, or to an IOMAD release built on one of those versions.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Vincent Schneider (finder)