CVE-2022-0335 Overview
A Cross-Site Request Forgery (CSRF) vulnerability was discovered in Moodle's "delete badge alignment" functionality. The flaw exists because this feature does not include the necessary token check to prevent unauthorized cross-site requests. An attacker could exploit this vulnerability by crafting a malicious web page that, when visited by an authenticated Moodle user, would trigger unauthorized badge alignment deletions without the user's knowledge or consent.
Critical Impact
This CSRF vulnerability allows attackers to perform unauthorized actions on behalf of authenticated Moodle users, potentially manipulating badge alignments and compromising the integrity of the learning management system's credentialing features.
Affected Products
- Moodle versions 3.11 to 3.11.4
- Moodle versions 3.10 to 3.10.8
- Moodle versions 3.9 to 3.9.11 and earlier unsupported versions
Discovery Timeline
- 2022-01-25 - CVE-2022-0335 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2022-0335
Vulnerability Analysis
This vulnerability is classified as CWE-352 (Cross-Site Request Forgery). The core issue lies in the missing anti-CSRF token validation within the badge alignment deletion functionality. When a user performs the delete badge alignment action, the application fails to verify that the request originated from a legitimate user session with a valid CSRF token.
In a properly secured implementation, state-changing operations like deletions should require a unique, unpredictable token that is tied to the user's session. This token must be validated server-side before processing the request. The absence of this validation in the affected Moodle versions creates an attack surface where malicious actors can forge requests.
Root Cause
The root cause of CVE-2022-0335 is the absence of CSRF token verification in the badge alignment deletion endpoint. Moodle's badge system allows administrators and users to manage badge alignments (connections between badges and external frameworks or competencies). The delete functionality accepts requests without validating that they include a session-specific CSRF token, allowing any authenticated request to be processed regardless of its origin.
Attack Vector
The attack requires user interaction - specifically, the victim must be authenticated to a vulnerable Moodle instance and must visit a malicious web page controlled by the attacker. The attack flow involves:
- The attacker identifies a target Moodle installation running a vulnerable version
- The attacker creates a malicious web page containing a hidden form or JavaScript that submits a request to the Moodle delete badge alignment endpoint
- When an authenticated Moodle user visits the malicious page, their browser automatically sends the forged request along with their valid session cookies
- The Moodle server processes the request as legitimate since it cannot distinguish between the forged request and a genuine user action
The vulnerability does not require any privileges on the attacker's part, only that they can induce a victim to visit their malicious page. For detailed technical information, refer to the Moodle Security Advisory.
Detection Methods for CVE-2022-0335
Indicators of Compromise
- Unexpected or unauthorized deletions of badge alignments in the Moodle database
- Unusual referrer headers in web server logs showing external domains triggering badge alignment deletions
- User reports of badge alignment modifications they did not perform
- Audit log entries showing badge alignment deletions without corresponding legitimate user activity
Detection Strategies
- Monitor Moodle audit logs for badge alignment deletion events and correlate with user activity patterns
- Implement web application firewall (WAF) rules to detect potential CSRF attack patterns targeting badge endpoints
- Review web server access logs for suspicious referrer headers on state-changing endpoints
- Deploy SentinelOne Singularity platform for endpoint monitoring to detect malicious web page access patterns
Monitoring Recommendations
- Enable verbose logging for the Moodle badges module to capture all badge-related operations
- Configure alerts for bulk or rapid badge alignment deletions that may indicate automated exploitation
- Monitor for anomalous user session behavior where actions occur without corresponding navigation patterns
- Implement real-time log analysis to identify CSRF exploitation attempts across the learning management system
How to Mitigate CVE-2022-0335
Immediate Actions Required
- Upgrade Moodle to version 3.11.5 or later, 3.10.9 or later, or 3.9.12 or later immediately
- Review Moodle audit logs to identify any potential exploitation prior to patching
- Conduct an assessment of badge alignment data integrity to detect any unauthorized modifications
- Educate users about the risks of clicking unknown links while authenticated to Moodle
Patch Information
Moodle has released security updates to address this vulnerability. Organizations should upgrade to the following patched versions:
- Moodle 3.11.5 or later for the 3.11.x branch
- Moodle 3.10.9 or later for the 3.10.x branch
- Moodle 3.9.12 or later for the 3.9.x branch
For detailed patch information and upgrade instructions, refer to the Moodle Security Forum Discussion and the Red Hat Bug Report.
Workarounds
- Implement additional WAF rules to validate referrer headers on sensitive Moodle endpoints as a temporary measure
- Restrict access to the badge management functionality to trusted internal networks until patching is complete
- Enable SameSite cookie attributes to Strict or Lax in Moodle's configuration to provide partial CSRF protection
- Consider temporarily disabling the badge alignment feature if it is not critical to operations until the patch can be applied
# Check current Moodle version
cd /path/to/moodle
php admin/cli/cfg.php --name=release
# Verify CSRF protection configuration in Moodle config.php
grep -i "sesskey" config.php
# Review badge-related log entries for suspicious activity
grep -i "badge" /path/to/moodle/moodledata/temp/logs/*.log
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

