Description

A flaw was found in Moodle. Incorrect handling of IPv4-mapped IPv6 addresses within the URL downloader's host-blocking logic allows an authenticated remote user to bypass blocked-host restrictions. By supplying a crafted URL, an attacker can induce the server to make requests to restricted destinations, leading to Server-Side Request Forgery (SSRF).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-30T09:17:14.660Z",
  "pubdate": "2026-09-30T09:17:14.660Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in Moodle due to improper validation of IPv4-mapped IPv6 addresses within the URL downloader's host-blocking logic.\nThe vulnerability allows an authenticated remote user to bypass established blacklist restrictions by obfuscating target host addresses using IPv6 mapping syntax.\nBy inducing the server to perform arbitrary outbound HTTP requests, an attacker can interact with internal network resources or services that are otherwise protected from external access.\nThis flaw impacts the Moodle URL downloader component. Successful exploitation requires an authenticated Moodle account with the ability to trigger URL downloads.\nThe primary risk involves the exposure of sensitive internal infrastructure, potential service disruption, or unauthorized access to internal metadata services and private APIs accessible to the web server.\nThis vulnerability highlights a critical failure in input sanitization and protocol-level address resolution within the security boundary of the downloader module.",
  "technicalDetails": "The root cause of this vulnerability is an address parsing discrepancy between the URL downloader's security filter and the underlying network stack of the host server. The security mechanism designed to enforce host-blocking relies on a blacklist that is not equipped to normalize IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1).\nWhen the Moodle URL downloader evaluates a URL, it performs a check to determine if the target hostname resolves to an unauthorized IP address or a loopback address. However, the logic fails to resolve or equate the IPv6-mapped representation to the actual IPv4 destination. Consequently, the filter permits the request to pass because the mapped address does not match the blocklist entries, even though the host system interprets the address as the internal resource upon connection.\nThe attack flow proceeds as follows: First, the attacker identifies a URL download feature within Moodle that accepts user-supplied input. Second, the attacker crafts a malicious request URL utilizing an IPv4-mapped IPv6 address to target a restricted internal endpoint, such as 'http://[::ffff:127.0.0.1]:80/' or an internal cloud metadata service. Third, the URL downloader's host-blocking logic evaluates the string, fails to recognize the address as a forbidden local or internal resource, and permits the downloader to proceed with the request.\nThe server, upon attempting to fetch the content from the provided URL, resolves the IPv4-mapped address to the internal destination. The server-side request is then executed against the target service, which treats the request as originating from the local web server itself. This bypasses network-level access controls and firewall rules that might otherwise restrict access to internal services.\nAuthentication is required to trigger the vulnerable functionality, limiting the attack vector to authenticated users. However, since many Moodle installations permit user registration or have low-privileged roles, this exposure is significant. The impact of successful exploitation includes potential unauthorized access to sensitive data, information disclosure regarding internal infrastructure, and the ability to port scan or probe internal network segments through the Moodle server's request context."
}