CVE-2026-7274

Overview

Moodle is an open source learning management system written in PHP. Schools, universities, and companies use it to run online courses. IOMAD is a multi-tenant distribution of Moodle that lets one installation serve several companies or organizations; it is built on Moodle core and shares the affected code. The external database authentication plugin (auth_db) lets a site check usernames and passwords against a table in a separate database, such as a student information system.

A SQL Injection vulnerability (CVE-2026-7274) has been identified in the auth_db plugin of Moodle and IOMAD, which allows an attacker to inject SQL into queries that Moodle runs against the external database, starting from the username field of the login form. Only sites with the external database authentication plugin enabled are affected. Moodle tracks this issue as MSA-26-0005 (MDL-88138).

Per OWASP: A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

This issue affects all versions of Moodle before 4.5.11, versions 5.0.0 through 5.0.6, and versions 5.1.0 through 5.1.3, including End-of-Life release lines such as Moodle 4.3. IOMAD releases built on these Moodle versions contain the same code and are affected as well.

Details

Module Info

• Product: Moodle, IOMAD
• Affected packages: moodle/moodle (auth/db)
• Affected versions: <4.5.11, >=5.0.0 <5.0.7, >=5.1.0 <5.1.4
• GitHub repository: https://github.com/moodle/moodle (Moodle), https://github.com/iomad/iomad (IOMAD)
• Published packages: https://packagist.org/packages/moodle/moodle
• Package manager: Composer
• Fixed in:
  • OSS Moodle 4.5.11, 5.0.7, 5.1.4
  • NES for Moodle v4.3.13
  • NES for IOMAD v4.3.4

Vulnerability Info

This High-severity vulnerability is found in the moodle/moodle package in all versions before 4.5.11, 5.0.0 through 5.0.6, and 5.1.0 through 5.1.3 of Moodle, and in IOMAD releases built on those versions. Moodle rates it Serious.

The auth_db plugin talks to the external database through ADOdb, not through Moodle's own database layer. It built its queries by pasting the username into the SQL string after passing it through ext_addslashes(). auth_plugin_db::user_login(), the code that runs when someone submits the login form, did this in both of its branches:

$rs = $authdb->Execute("SELECT *
                          FROM {$this->config->table}
                         WHERE {$this->config->fielduser} = '".$this->ext_addslashes($extusername)."'");

get_userinfo() and user_exists() built their queries the same way, and user_update() wrote changed profile values into an UPDATE statement through the same helper. ext_addslashes() is not a safe substitute for bound parameters. Unless the sybasequoting setting is on, it escapes a quote by putting a backslash in front of it:

function ext_addslashes($text) {
    if (empty($this->config->sybasequoting)) {
        $text = str_replace('\\', '\\\\', $text);
        $text = str_replace(array('\'', '"', "\0"), array('\\\'', '\\"', '\\0'), $text);
    } else {
        $text = str_replace("'", "''", $text);
    }
    return $text;
}

That only works when the external database treats a backslash as an escape character. Databases that follow the SQL standard, such as PostgreSQL with its default settings, Microsoft SQL Server, and Oracle, treat the backslash as an ordinary character, so the quote that follows it still ends the string. A username such as ' OR 1=1 -- becomes \' OR 1=1 --, and the database reads it as the one-character string \ followed by the attacker's own SQL. Character-set mismatches between Moodle and the external database can defeat the escaping in a similar way.

The username comes straight from the login form, so the login path can be reached without an account. The injected SQL runs with the privileges of the database account that Moodle uses for the external database, which can let an attacker read or change data in that database and interfere with the authentication decisions Moodle makes from it. Sites that do not use the external database authentication plugin are not exposed.

The fix replaces every query that included user input with a ? placeholder and passes the value to ADOdb's Execute() as a bound parameter:

$rs = $authdb->Execute("SELECT *
                          FROM {$this->config->table}
                         WHERE {$this->config->fielduser} = ?", [$extusername]);

user_update() now builds its SET clause from field = ? pairs with a matching parameter list. ext_addslashes() remains in the class for backward compatibility but is no longer used to build queries.

Mitigation

Moodle publishes security fixes only for its supported release lines. Earlier release lines, including Moodle 4.3 and the IOMAD releases built on it, are End-of-Life and will not receive any public updates to address this issue.

Until an upgrade is possible, sites that use external database authentication can reduce the risk by connecting with a database account that can reach only the user table and has no more privileges than the plugin needs, or by switching to another authentication method.

Users of the affected components should apply one of the following mitigations:

• Upgrade to Moodle 4.5.11, 5.0.7, 5.1.4, or later, or to an IOMAD release built on one of those versions.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Melvinsh (finder)
• McCaulay Hudson (finder)