When we think about security vulnerabilities, we often look for something complex or hidden deep inside application logic. But sometimes, a critical flaw lies right on the surface, tucked away in places we don’t expect. CVE-2022-30596 is a perfect example. This issue affected Moodle, one of the world’s most popular open-source learning management systems.

Let’s break down what this vulnerability is, how it works, see it in action with a code snippet, and understand the fix. If you use Moodle or care about web security, this real-life simple bug is worth your attention.

What Is CVE-2022-30596?

CVE-2022-30596 is a stored cross-site scripting (XSS) vulnerability that affected Moodle, specifically when using the “bulk allocate markers to assignments” feature in assignment grading.

The Problem:  
Marker (grader) allocation allows teachers to assign specific graders to groups of students. However, when displaying the “ID number” field in this process, Moodle didn’t sanitize the ID number properly. If someone (like an attacker with editing rights) put malicious JavaScript code in the ID number, it would be rendered by the browser—providing a pathway for XSS attacks.

Risk:  
- A user with permission to set ID numbers could inject malicious JavaScript, which would then execute for teachers or admins managing assignments.

Here’s a simple explanation

1. A Moodle user with permissions (like a teacher or course manager) finds a place to set a User or Assignment “ID number.”  
2. They save the field using JavaScript instead of a normal ID, e.g., <script>alert('XSS')</script>.
3. When another user opens the “Allocate markers” page, Moodle renders the field directly into the page without escaping—it runs as real code.

This is a classic *stored* XSS: the code is saved to the database and shown to other users.

Exploiting CVE-2022-30596: PoC Code

Let’s see a practical example of how this works.

Step 1: Inject a Malicious ID Number

Suppose you’re a teacher or manager and have access to set user or assignment ID numbers. Enter something malicious, such as:

<script>alert('Hacked by XSS!')</script>

Assignment “ID number” under Assignment settings.

!Screenshot: Inserting XSS payload in ID number field

Go to the Assignment > Grade > "Allocate markers" bulk page.

2. If the allocation table displays the ID number, you'll see your script execute. For example, in Chrome, you get an alert popping up:

alert('Hacked by XSS!')

This code could be swapped for anything—stealing cookies, session tokens, or more targeted attacks.

Here’s a (simplified) version of what the vulnerable code might have looked like (in PHP)

// BAD: Echoing unsanitized database data into HTML
echo "<td>" . $user->idnumber . "</td>";

No escaping or sanitizing means HTML tags and scripts run as code.

The Fix:

Ensuring output is escaped for HTML

// GOOD: Using Moodle's safe output functions
echo "<td>" . s($user->idnumber) . "</td>";
// or, using Moodle's html_writer:
echo html_writer::tag('td', $user->idnumber);

Now < and > are rendered as simple text, not as HTML tags.

Potential Impact

- Unauthorized JavaScript can hijack sessions, modify grades, redirect users, or steal information.
- This can be especially damaging in educational institutions with multiple roles and less-experienced admins.

What Did Moodle Do?

Moodle HQ fixed this issue in versions 3.9.17, 3.11.13, and 4..3.

> *“ID numbers displayed when bulk allocating markers to assignments now have additional sanitizing applied to prevent a stored XSS risk.”*  
Official Release Note (search “CVE-2022-30596”)

Upgrade your Moodle instance to the latest stable version to stay safe.

More References

- NVD entry for CVE-2022-30596
- Moodle Security Announcements

Audit user permissions: Limit access to set ID numbers.

- Test your system: Try inputting <script>alert(1)</script> in user fields, and see if the code runs.

Summary

CVE-2022-30596 is a reminder that even simple fields, like “ID number,” can become avenues for attackers if your app doesn’t properly sanitize user input before rendering it. Stored XSS is especially dangerous because the payload lives in the database and affects other users.

Always sanitize before displaying database content, especially in widely used applications like Moodle.

Stay patched, stay safe, and don’t trust user input—even in fields like “ID number.”

*If you want to test your security knowledge, review your systems for similar flaws. You never know what a harmless field might be hiding!*

Timeline

Published on: 05/18/2022 17:15:00 UTC
Last modified on: 06/13/2022 14:46:00 UTC