Moodle Security in 2026: The CVEs to Patch and What to Do If You Can't Upgrade

On 22 July 2026, Moodle published a security advisory (CVE-2026-18025) warning that its mobile app could read the login tokens a user had saved for other Moodle sites. It was the third serious Moodle vulnerability disclosed in 2026, after a remote code execution flaw and a SQL injection bug earlier in the year. If you self-host Moodle, that run of advisories is your prompt to check exactly which version you are on and what still affects it.

The 2026 Moodle security advisories, in order

Moodle discloses vulnerabilities through its security announcements forum and assigns each one a CVE. Three from 2026 matter most for self-hosted sites, and two of them share a single fix. Here is the short version before the detail.

The two May 2026 advisories, CVE-2026-7275 and CVE-2026-7274, were reported through Moodle's tracker (MDL-88423 and MDL-88138) and are fixed in the same three releases. The July advisory affects the Moodle mobile app, not the server, and is fixed in app version 5.2.1.

What each vulnerability actually lets an attacker do

CVE-2026-7275 is a remote code execution flaw in Moodle's Google Drive repository plugin. Remote code execution is the most serious class of web vulnerability, because it can let an attacker run their own code on the server that hosts your site. If you cannot patch immediately, Moodle's advised workaround is to disable the Google Drive repository plugin.

CVE-2026-7274 is a SQL injection flaw in the external database authentication plugin (auth_db), which some sites use to authenticate users against an outside database. SQL injection can let an attacker manipulate the queries your site runs, putting the confidentiality and integrity of your database at risk. It is fixed in the same 5.1.4, 5.0.7 and 4.5.11 releases.

CVE-2026-18025 is different, because it lives in the Moodle mobile app rather than on your server. A site logged into the app could read the secure-storage tokens for other Moodle sites the same user had configured, which could expose those sites' web-service tokens. Updating the app to version 5.2.1 closes it, so tell your mobile users to update.

Why this is harder than 'just update Moodle'

"Patch promptly" is the right advice and the hardest to follow. Moodle ships a new major version about every six months, and pushes security releases for supported branches whenever vulnerabilities are found. Keeping pace sounds simple until you try it on a production site that people depend on every day.

• PHP and database requirements: a newer Moodle needs newer PHP, which can force a server upgrade first.
• Plugin compatibility: a third-party plugin that has not been updated can break on the new version.
• Custom themes and code: bespoke work often needs re-testing or porting before you dare upgrade.
• Downtime and change windows: institutions can only take the site offline at certain times of year.
• Unsupported versions: if you are on 4.4, 4.3 or older, there is no security release to apply at all.

None of this is unique to security. It is the same operational drag that shapes the choice between managed and self-hosted Moodle hosting, and it runs through the broader trade-offs of running Moodle. The difference is that a security advisory puts a clock on it.

How to check whether your site is affected

You cannot decide what to do until you know your exact version and which entry points are live. This takes about five minutes inside your own admin area.

Harden every Moodle site, patched or not

Patching closes the specific holes. These controls shrink the damage of the next one, and most take an afternoon. Work through them regardless of which version you are on.

What to do if you cannot upgrade right now

Plenty of sites are stuck on an older release for a reason that is not going away this week. That is the same lesson as the 2026 Canvas data breach: your learners' data is only as safe as your least-patched system. The move is to reduce exposure now, not to wait for the perfect upgrade window.

Start by turning off the entry point: for CVE-2026-7275, disable the Google Drive repository plugin. Then get the specific security patches back-ported to your current release, so you close the hole without a full version jump. Cubite's Moodle security audit does exactly this, back-porting critical fixes to older branches such as 3.9, 4.1, 4.3 and 4.4 for teams that cannot upgrade normally yet, and its free tool shows which advisories still affect your exact version.

Where a managed audit helps, and where it does not

Be honest about this. If you run a supported version and apply security releases within days, you are already doing the most important thing, and an audit will mostly confirm it. A well-maintained self-hosted Moodle is a secure Moodle, and you do not need anyone for that.

An audit earns its place in the harder cases: you are several versions behind, an upgrade is blocked by PHP or plugin compatibility, or nobody on the team has time to track advisories. In those situations, knowing precisely which of the 2026 CVEs still reach your install, and getting the fixes without a risky full upgrade, is the difference between a clock that is ticking and a hole that is closed.

Frequently asked questions about Moodle security in 2026