CVE-2024-25983

What it actually does

Insufficient authorization checks in a web service endpoint allow an authenticated user to add comments to another user's dashboard comments block even when the block is not visible or editable on the target's profile or dashboard pages.

Why it matters to the business

Low-privileged accounts can inject unwanted content into other users' personal dashboards, leading to confusion, harassment, or degraded trust in the platform's collaboration features.

How an attack unfolds

An attacker with a valid low-privilege account identifies a target user and issues a crafted request to the vulnerable web service that adds a comment to the target's dashboard comments block, bypassing the normal visibility and permission checks that would prevent the action from the profile page.

How to fix it

Upgrade all Moodle instances to the commit 8a38a37f1ff5075c6f46d726c1457172c2fccac3 or later versions that contain the authorization fix; apply the patch immediately given the public availability of the fix since February 2024.

How to confirm the fix worked

Confirm the presence of commit 8a38a37f1ff5075c6f46d726c1457172c2fccac3 in the codebase; test that attempts to add comments via the web service to another user's dashboard now correctly return authorization errors when the block is not otherwise available.

Typical attack path

1. Obtain a valid low-privilege authenticated session in the Moodle instance
2. Identify the target user ID or dashboard context
3. Craft and send a request to the web service endpoint responsible for adding comments
4. Bypass insufficient permission checks to write the comment directly to the target's dashboard block

How to detect it

Examine Moodle web service logs and comment creation audit records for entries where a user adds a comment to a dashboard that is not their own or that would normally be inaccessible; correlate with user activity timestamps around comment block updates.

What your security team should do

• Prioritize patching all Moodle deployments to the fixed commit within the next maintenance window
• Review web service access logs for any anomalous comment creation events prior to patching
• Consider temporarily disabling the comments block web service if immediate patching is not feasible