CVE-2026-58345

Incorrect Authorization
Affects
Moodle, IOMAD
in
Moodle
No items found.
Versions
<4.5.12, >=5.0.0 <5.0.8, >=5.1.0 <5.1.5, >=5.2.0 <5.2.1

Patch Available.

Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

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 assignment module's marking workflow can allocate a specific marker to each student's submission. Allocating markers is controlled by the mod/assign:manageallocations capability, which by default only editing teachers and managers have.

An Improper Access Control vulnerability (CVE-2026-58345) has been identified in the assignment module of Moodle and IOMAD, which allows a user who can open an assignment, such as a student or a non-editing teacher, to change which marker is allocated to submissions without holding the capability that controls marker allocation. Moodle tracks this issue as MSA-26-0026 (MDL-88529).

Per MITRE CWE-862: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

This issue affects all versions of Moodle before 4.5.12, versions 5.0.0 through 5.0.7, versions 5.1.0 through 5.1.4, and version 5.2.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

Vulnerability Info

This High-severity vulnerability is found in the moodle/moodle package in all versions before 4.5.12, 5.0.0 through 5.0.7, 5.1.0 through 5.1.4, and 5.2.0 of Moodle, and in IOMAD releases built on those versions. Moodle rates it Serious.

When an assignment uses marking workflow with marker allocation, the grading table offers a batch action that sets the allocated marker for the selected submissions. The grading page only offers that option to users with mod/assign:manageallocations, but the code behind it did not check the capability. assign::view() passes the viewbatchmarkingallocation action to view_batch_markingallocation(), which shows the allocation form, and the setbatchmarkingallocation action to process_set_batch_marking_allocation(), which saves it. The save handler went straight to loading the form:

    protected function process_set_batch_marking_allocation() {
        global $CFG, $DB;

        // Include batch marking allocation form.
        require_once($CFG->dirroot . '/mod/assign/batchsetallocatedmarkerform.php');

Further down, it reads the list of user IDs and the chosen marker from the submitted form and updates each user's flags:

        if ($formdata = $mform->get_data()) {
            $useridlist = explode(',', $formdata->selectedusers);
            $marker = $DB->get_record('user', array('id' => $formdata->allocatedmarker), '*', MUST_EXIST);

            foreach ($useridlist as $userid) {
                $flags = $this->get_user_flags($userid, true);

The only check on the way in is in mod/assign/view.php, which requires mod/assign:view. Students and non-editing teachers have that capability by default but do not have mod/assign:manageallocations. Either of them can submit the allocation form directly and set a different allocated marker on submissions, as long as those submissions have not yet reached the ready for review, in review, ready for release, or released workflow states. The display handler had the same gap, so the form itself, with summaries of the selected users and the list of potential markers, was also shown without the check.

The impact is limited to who is allocated to mark a submission. The request does not change grades, feedback, or the submissions themselves.

The fix adds a capability check at the start of both handlers, so the form can neither be shown nor processed without mod/assign:manageallocations:

    protected function process_set_batch_marking_allocation() {
        global $CFG, $DB;

        require_capability('mod/assign:manageallocations', $this->context);

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.

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

  • Upgrade to Moodle 4.5.12, 5.0.8, 5.1.5, 5.2.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

  • Paul Holden from Moodle HQ (finder)
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
High
ID
CVE-2026-58345
PROJECT Affected
Moodle, IOMAD
Versions Affected
<4.5.12, >=5.0.0 <5.0.8, >=5.1.0 <5.1.5, >=5.2.0 <5.2.1
NES Versions Affected
Published date
October 14, 2026
≈ Fix date
October 1, 2026
Category
Incorrect Authorization
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Moodle
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.