CVE-2025-62399 is an authentication brute force vulnerability in Moodle's mobile and web service endpoints. The flaw allowed automated password-guessing attacks against a learning management system used by over 500 million users worldwide on registered Moodle sites. Standard login form protections were in place, but the same lockout and rate-limiting controls were not applied to the mobile API and REST authentication code paths, leaving those entry points open to automated credential attacks.
TLDR:
- CVE-2025-62399 is a CWE-307 authentication brute force flaw in Moodle's mobile and web service endpoints
- The
/login/token.phpendpoint and related API paths lacked the same rate limiting and lockout controls as the main login form - Affected versions: Moodle 4.1.0-4.1.20, 4.4.0-4.4.10, 4.5.0-4.5.6, and 5.0.0-5.0.2 when mobile or web services were activated
- Fixed in: Moodle 4.1.21, 4.4.11, 4.5.7, and 5.0.3
- Any deployment with mobile or web services turned on was exposed
What is CVE-2025-62399?
CVE-2025-62399 is a brute force authentication vulnerability in Moodle, classified under CWE-307 (Improper Restriction of Excessive Authentication Attempts) with a CVSS score of 7.5 HIGH. The core problem: Moodle's standard login page enforced account lockout and rate limiting, but those protections were not consistently applied to the mobile app and REST API authentication paths. Attackers could automate password-guessing attempts against those unprotected endpoints without triggering any lockout, making credential stuffing or dictionary attacks viable against Moodle deployments with mobile or web services active.
Moodle is the world's most widely used open-source learning management system, with over 500 million registered users across schools, universities, and enterprise training platforms. A flaw in its authentication mechanisms has a large blast radius for the global education sector.
How the Moodle authentication brute force worked
Attack surface and root cause
The attack surface was the /login/token.php endpoint, which Moodle's mobile apps and external integrations use to obtain authentication tokens. Unlike the standard web login form, this endpoint did not trigger the same lockout counter. An attacker with a list of known or collected usernames could point an automated script at this endpoint and submit a high volume of password guesses without any throttling, running unimpeded until a valid credential is found.
No public exploit code was released, and no specific vulnerable code locations were disclosed. The root cause was an inconsistency in the application of lockout controls across Moodle's authentication code paths. The fix extended rate-limiting and lockout enforcement to cover the mobile and REST API paths, bringing them into parity with the main login form.
How an attacker would exploit it
In practice, an attacker would start by collecting valid usernames. Moodle's course enrollment and profile endpoints have historically exposed user data in misconfigured instances, and many institutions publish staff or student email formats publicly. With a username list in hand, the attacker points a credential-stuffing tool at /login/token.php, submitting POST requests with username, password, and service=moodle_mobile_app parameters. Because no lockout counter fired on this path, a tool like ffuf or Hydra could cycle through thousands of password candidates per account without restriction. A valid credential returns a token in the JSON response; an invalid one returns an error code. That response asymmetry also serves as a username enumeration signal, letting an attacker confirm which accounts exist before the password phase starts.
Affected Moodle versions and fixed releases
The vulnerability was present when mobile or web services were activated.
Branch | Affected versions | Fixed release |
|---|---|---|
Moodle 5.0.x | 5.0.0 to 5.0.2 | 5.0.3 |
Moodle 4.5.x | 4.5.0 to 4.5.6 | 4.5.7 |
Moodle 4.4.x | 4.4.0 to 4.4.10 | 4.4.11 |
Moodle 4.1.x | 4.1.0 to 4.1.20 | 4.1.21 |
Earlier unsupported | All versions | No patch available |
Patching CVE-2025-62399 and hardening Moodle authentication
Applying the patch
Upgrading to a fixed release is the primary remediation. Moodle 5.0.3, 4.5.7, 4.4.11, and 4.1.21 all include the fix. For deployments that cannot patch immediately, interim steps reduce exposure while the patch is staged.
Interim mitigations
If mobile or web services are not actively in use, disabling them removes the exposed attack surface entirely. Mobile services can be toggled off under Site administration > Mobile app > Mobile settings. REST API endpoints are managed separately under the Advanced features section.
For deployments that require mobile or web services, rate limiting at the network layer provides compensating control while the patch is staged. Configuring a WAF or reverse proxy to cap the request rate to /login/token.php per source IP limits the speed and scale of brute force attempts, even if it does not close the underlying gap on its own.
Monitoring authentication logs for high volumes of failed token requests from a single IP is a practical detection signal. Moodle's built-in login failure logs and standard web server access logs both capture this data. A spike in POST requests to /login/token.php paired with repeated error responses is the pattern to watch.
After applying the patch, audit all authentication entry points to confirm that lockout and rate-limiting controls apply consistently. CVE-2025-62399 was one gap. Others may exist in custom plugins, third-party integrations, or API endpoints added later that never went through the same security review as the main login form.
Moodle security history and past authentication flaws
Moodle maintains a mature security disclosure process with coordinated advisories published across all supported branches. Prior reported vulnerabilities include authentication bypass in quiz functionality, remote code execution via formula validation flaws, and information disclosure in user profile handling. Patch response for issues rated critical is typically prompt, with fixes released across all supported branches in parallel. The project runs a dedicated security team and public advisory channels.
What related Moodle authentication issues were disclosed after the patch?
CVE-2025-62399 was not an isolated case. After it was patched, Moodle disclosed MSA-25-0057 (CVE-2025-67853), a separate rate-limiting gap in the confirmation email web service (rated Minor by Moodle) that again allowed password checks against known usernames. Moodle also disclosed CVE-2026-7274 in May 2026 (rated Serious by Moodle), an SQL injection in the external database authentication plugin, showing that authentication code paths across the platform have continued to draw research attention.
A mid-2025 Cybernews investigation uncovered 16 billion stolen credentials across 30 leaked datasets, most originating from infostealer malware, reinforcing that any authentication endpoint without consistent controls is an active target for automated attacks. Administrators running deployments with mobile or web services activated should confirm their installation is on a patched release and review rate-limiting configuration across all authentication entry points.
How ZeroPath detects authentication vulnerabilities like CVE-2025-62399
CVE-2025-62399 is a class of vulnerability that pattern-matching scanners routinely miss. A rule-based tool can flag SQL injection by detecting string concatenation in a query, but it cannot reason about whether a rate-limiting control is missing from one code path while present in another. That requires understanding the application's authentication flows end-to-end.
ZeroPath's multi-stage AI scanning pipeline treats authentication vulnerabilities as a first-class detection category, including missing authentication checks, broken authentication flows, session handling flaws, and authorization bypasses. Its software property graph architecture models data and control flows across the codebase, testing whether security controls hold consistently across all code paths, beyond those where a developer remembered to apply them.
For a Moodle-style deployment with web services active, ZeroPath would flag the inconsistency between the main login form's lockout logic and the API token endpoint's handling. That is the class of finding CVE-2025-62399 represents: a control present in one code path, absent in another, invisible to tools that only match syntax.
The deeper problem this vulnerability represents is not a missing function call. There is no single line of code that, if present, would have caught this during development. The flaw is relational: lockout logic exists in one code path and is absent in another. Detecting that absence requires a tool that builds a model of the application's authentication architecture, maps where credentials are accepted, traces which paths call into the lockout-enforcement logic, and flags paths that skip it. ZeroPath's software property graph explicitly models those control-flow relationships. It does not check whether a security function exists somewhere in the codebase. It checks whether the function is reachable from every input that requires it.
Final thoughts on CVE-2025-62399
CVE-2025-62399 is a reminder that authentication controls need to be applied consistently across every entry point in an application, including those that do not appear in a browser. Moodle's main login form was protected; the mobile and API paths were not. That gap was the vulnerability. Security teams responsible for platforms with large user bases should audit authentication code paths for missing or inconsistent controls. See how ZeroPath maps authentication flows across your codebase. ZeroPath's software property graph traces which code paths reach lockout enforcement and which ones skip it, making gaps like CVE-2025-62399 visible before they ship. Catching that class of inconsistency before it reaches production requires a tool that models authentication flows across the entire codebase, not one that pattern-matches syntax.
FAQ
What is CVE-2025-62399?
CVE-2025-62399 is a brute-force authentication vulnerability in Moodle, classified under CWE-307. It allowed automated password-guessing attacks against the mobile app and web service authentication endpoints because those paths did not enforce the same rate-limiting and lockout controls as the standard web login form.
Which Moodle versions are affected by CVE-2025-62399?
The vulnerability affected Moodle 4.1.0 through 4.1.20, 4.4.0 through 4.4.10, 4.5.0 through 4.5.6, and 5.0.0 through 5.0.2, as well as all earlier unsupported versions, when mobile or web services were activated.
How was CVE-2025-62399 fixed?
Moodle extended rate-limiting and account-lockout controls to cover the mobile and REST API authentication paths, bringing them into parity with the main login form. Fixed releases are 4.1.21, 4.4.11, 4.5.7, and 5.0.3.
Was CVE-2025-62399 exploited in the wild?
No public exploit code or confirmed in-the-wild exploitation was disclosed. The attack technique, automated requests to /login/token.php, is straightforward, and the vulnerability window spanned widely deployed Moodle versions.
Are there any related Moodle authentication vulnerabilities to know about?
Yes. After CVE-2025-62399 was patched, Moodle disclosed MSA-25-0057 (CVE-2025-67853), a rate-limiting gap in the confirmation email web service, and CVE-2026-7274, a SQL injection in the external database authentication plugin. Administrators should check Moodle's security advisory channel for the full disclosure history.
