A significant security vulnerability (CVE-2022-45152) was discovered in Moodle, the widely used open-source learning management system. This bug is a Blind Server-Side Request Forgery (SSRF) found within the LTI provider library. In this exclusive post, we’ll break down what this means, how the exploit works, and what you can do to protect your Moodle instance.

What Is SSRF?

Server-Side Request Forgery (SSRF) is a vulnerability in which an attacker tricks a server into making HTTP (or other protocol) requests to a destination the attacker chooses. “Blind” SSRF means the response is not directly visible, but the request is executed anyway — often leaving traces only in network logs or by triggering side effects.

Where's The Bug?

The problem sits inside the mod/lti provider code. Instead of using Moodle’s secure, audited download_file_content or its cURL helper functions, a portion of the code uses plain PHP core functions — like file_get_contents — to fetch remote URLs. This poor design means user-controlled input can dictate exactly where Moodle sends outbound HTTP requests.

Here’s the original advisory on moodle.org.

Vulnerable if the LTI provider plugin is enabled.

Refer to the official Moodle Security Notices for full details.

Suppose you have code similar to

// Hypothetical example based on research
$url = $_GET['url']; // User can control the url parameter

$response = file_get_contents($url); // BAD: no validation!

If not properly validated, someone could supply http://internal-server/secret to probe internal resources.

The fix: Always use secure wrappers and validate targets.

require_once($CFG->libdir.'/filelib.php');

$url = required_param('url', PARAM_URL); // Sanitized input

$response = download_file_content($url); // Uses Moodle’s cURL helper with restrictions

Exploitation Steps

1. Craft a Malicious LTI Link: The attacker creates an LTI request referencing an attacker-controlled or internal URL.
2. Trigger Processing: The vulnerable Moodle instance processes incoming request with the arbitrary destination.
3. Blind SSRF: The attacker can cause Moodle to reach any system the server can access — including internal-only systems behind firewalls.

Attack with a DNS logger

https://victim-moodle.com/mod/lti/launch.php?url=http://<your-unique-subdomain>.burpcollaborator.net

If you get a callback in your Collaborator logger, the SSRF is working!

Impact

- Scan internal networks: Attackers can use the server’s access to swarmed internal resources — sometimes revealing admin panels, cloud metadata, other sensitive endpoints.

Bypass firewalls: SSRF can be used to access systems not otherwise exposed to the internet.

- Pivot attacks: May be combined with other vulnerabilities (such as internal admin panels with default credentials).
- Data exfiltration: May be possible if SSRF responses leak elsewhere, or data is forwarded by the secondary request.

Mitigation

Update Now:  
Official patches are available in Moodle 4..6, 3.11.12, and 3.9.19.  
- See official advisory

Sanitize all user input.

- Use framework/built-in HTTP libraries that employ allowlist validation and destination restrictions.

Original References

- Moodle Security Advisory – MDL-76552
- National Vulnerability Database Entry
- Moodle Security Notices

TL;DR

A critical blind SSRF in Moodle’s LTI provider meant an attacker could trick the server into making hidden HTTP requests anywhere, putting internal systems at risk. This happened because developers didn’t use Moodle’s own safe cURL helpers.  
Update your Moodle installations today, disable unneeded plugins, and never trust user input as a URL.

*For more details or help, visit* moodle.org/security.


*Stay safe. Patch early. Share with your IT & dev teams!*

Timeline

Published on: 11/25/2022 19:15:00 UTC
Last modified on: 02/01/2023 15:58:00 UTC