Moodle MAT: The Hidden Risk of Departmental Moodles in 2026

Moodle MAT is what students and lecturers at UnB call the virtual environment of the Mathematics Department, hosted at moodle.mat.unb.br, and the term has risen in Brazilian searches this week. The coincidence is uncomfortable: on 10 August 2026 the Moodle project published fixes for the four still-supported versions. Anyone looking after a departmental instance has only a few days' head start.

TL;DR

• On 10 August 2026 versions 5.2.2, 5.1.6, 5.0.9 and 4.5.13 were released — all with security fixes whose details only become public about a week later.
• Departmental instances like Moodle MAT often fall outside the central IT inventory: no owner, no maintenance window, no staging environment.
• 5 October 2026 is the date that decides everything: 5.1 loses general support, 5.0 loses even security support, and 5.3 LTS is released.
• The jump to 5.1 or higher requires pointing the server's document root to the /public folder and relocating third-party plugins. That's where most upgrades stall.
• 5.2 raises the technical floor (PHP 8.3, PostgreSQL 16, MySQL 8.4, MariaDB 10.11) and brings Google Gemini and AWS Bedrock as AI providers in the core.

What is Moodle MAT — and why it matters beyond UnB

Moodle MAT is a classic case of a departmental instance: its own Moodle, maintained by an academic department, running in parallel to the university's institutional environment. It exists for a legitimate reason. Mathematics has needs that the central virtual environment rarely meets well — LaTeX formula rendering, question banks with random variables, automatically marked exercise sheets, and cohorts that span several semesters without being deleted.

The pattern repeats across Brazil. Science departments, laboratories, postgraduate programmes, government schools, internal training units: each set up its own Moodle on the day it needed freedom that central IT didn't provide. The result is a mesh of installations that no one can see from above.

To gauge the scale: the project's public dashboard at stats.moodle.org counts 146,104 registered Moodle sites worldwide, with Brazil in 5th place with 6,895 installations — behind Spain (12,554), the United States (12,032), Germany (7,927) and Mexico (7,800). And here's the detail that changes how you read that number: registration is voluntary. Every Moodle MAT that was never registered is missing from that count. The real total of Brazilian instances is higher — probably much higher.

The 10 August 2026 release: four versions on the same day

On 10 August 2026 the project released, simultaneously, Moodle 5.2.2, 5.1.6, 5.0.9 and 4.5.13. Publishing all supported branches on the same day is the project's typical behaviour when there is a security fix in the package.

And there is. The release notes carry the phrase administrators have learned to fear: details of the fixed flaws will be disclosed after approximately one week. The logic is sensible — giving time to update before the attack recipe becomes public.

Translated into the calendar: if you're reading this on 13 August 2026, you have a few days of grace. Around the 17th, the corresponding MSA bulletins go live at moodle.org/security and anyone can map which versions are vulnerable and how.

This isn't theory. The previous round, on 22 June 2026, brought bulletins MSA-26-0026 to MSA-26-0029: blind SSRF in the MNet peers function, denial-of-service risk via user profile description, and two permission-checking flaws — one in the report builder, another in the assignment module's marker allocation. Before those, MSA-26-0006 addressed a remote code execution risk via the Google Drive repository plugin, catalogued as CVE-2026-7275.

None of these flaws require a sophisticated attacker. They only require an installation stuck in time — which is exactly the profile of a typical departmental Moodle.

The calendar that decides the fate of your Moodle MAT

The official lifecycle is published at moodledev.io/general/releases and is the document that should be pinned to the wall of anyone administering any instance:

Version	Release	End of general support	End of security support
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026	04/10/2027	01/10/2029

Three practical readings of this table:

1. If your Moodle MAT runs 5.0, the clock stops on 5 October 2026. After that, there are no more security fixes for that branch. Less than two months remain.
2. If it runs 4.5 LTS, you've already had no common bug fixes since October 2025 — only security, and that only until October 2027. You can breathe, but not relax.
3. If it runs 5.1, general support ends on 5 October 2026, but security continues until April 2027. It's the most comfortable position to plan an upgrade without rushing.

And there's a planning opportunity almost nobody takes advantage of: 5.3 LTS arrives on 5 October 2026, with security support until 1 October 2029. For a departmental instance, with no dedicated team and no recurring budget, LTS is almost always the right choice. Three years of predictability are worth more than new features nobody will use.

Why departmental instances age faster

It's not laziness. It's structure. Moodle MAT is born this way in any institution, always for the same three reasons.

There is no formal owner

The installation was done by an enthusiastic lecturer, a scholarship student, or a technician who has since moved on. When the server needs attention, there's no one to turn to. The system keeps working — and working is precisely what postpones maintenance. Nobody updates what isn't broken, even when what's broken is invisible.

There is no maintenance window

The institutional environment has a downtime schedule negotiated with the rector's office. The departmental one doesn't. Every week is exam week, assignment deadline, or grade submission. Without a scheduled window, the update on the department's Moodle MAT is always postponed to "after the semester" — and the semester never ends.

There is no staging environment

Updating directly in production is a gamble. Anyone who has seen an upgrade break a formula plugin at 11pm on a Sunday before an exam doesn't repeat the mistake: they simply stop updating. The fear here is rational. The solution is also simple — a clone of the environment to test first — but it requires someone to take on the task.

The /public trap: why the jump to 5.1 stalls

From Moodle 5.1 onwards, the code has been restructured. Only the /public folder is accessible via the web; core, libraries and configuration now live outside the served directory. It's a real security gain, documented in the code restructuring guide — and it's also why so many upgrades stall.

Three practical consequences:

• The server's document root needs to point to the /public folder. On Apache, DocumentRoot /var/www/moodle/public; on Nginx, root /var/www/moodle/public;. Without this adjustment, Moodle simply won't load.
• The $CFG->wwwroot in config.php does not end in /public. Changing that line by mistake is the most common error for those upgrading on shared hosting, and it generates an error message that scares more than it should.
• Third-party plugins installed in the old structure need to be relocated to the equivalent path inside /public. Custom themes, formula plugins, videoconferencing integrations: each one needs to be checked individually.

In a Moodle MAT with ten plugins accumulated over eight years, the third item is usually what kills the project. Nobody remembers who installed them, where they came from, or whether they're still maintained. The practical advice we give clients is always the same: before touching the server, export the list of additional plugins and check each one's compatibility with the target version. An abandoned plugin is reason enough to postpone the upgrade — and to start looking for a replacement now, not in October.

Moodle 5.2 raises the technical floor (and brings AI into the core)

5.2, released on 20 April 2026, raised the minimum requirements: PHP 8.3 (with 8.4 supported), PostgreSQL 16, MySQL 8.4, MariaDB 10.11 or SQL Server 2019. If the server where your department's Moodle MAT lives runs PHP 8.1 and MariaDB 10.6 — a very common configuration on machines provisioned around 2021 — the upgrade stops being an application problem and becomes an infrastructure problem. That changes the timeline, the cost, and who needs to approve it.

On the features side, the news that interests those who teach is the arrival of two artificial intelligence providers in the Moodle core: Google Gemini (a community plugin promoted to core) and AWS Bedrock. In practice, you can enable summary generation, marking support and course assistants without relying on an external plugin — something that until 2025 required hand-built integration.

And here lies a new risk. One of the June bulletins, MSA-26-0024, dealt precisely with missing permission checks in AI placement web services. New features mean new attack surface. If the decision is to enable AI in the environment, the update discipline stops being optional from that day on.

Consolidate into the institutional environment or keep Moodle MAT separate?

There is no single answer. There are criteria. After operating critical EAD environments for over a decade, this is how we evaluate:

Consolidate into the central environment when:

• The department uses only standard features (assignment, quiz, forum, grade).
• There is no exclusive plugin in real use — only installed.
• The active base is small and the cost of maintaining your own server doesn't pay off.
• No one in the department wants (or can) take on formal technical responsibility.

Keep it separate when:

• There is real dependence on plugins that central IT doesn't approve.
• The department's academic calendar doesn't align with the institutional one.
• Research, extension or paid courses run there, with their own requirements.
• There is budget and a designated person for maintenance — not goodwill, but designation.

The classic mistake is the middle ground by inertia: keeping Moodle MAT separate without taking on the technical responsibility that separation demands. It's the worst of both worlds — autonomy without support, risk without benefit.

Checklist: auditing a departmental Moodle in an afternoon

This guide serves to audit Moodle MAT or any instance you've inherited. It takes less than three hours and already delivers a defensible diagnosis:

1. Find out the exact version. Site administration → Notifications shows the installed release. Compare with the lifecycle table above.
2. Check PHP and database. Site administration → Server → Environment shows what's below the minimum for the next version.
3. List additional plugins. For each one, note the name, version, and whether it still receives updates in the official directory.
4. Test restoring a backup. A backup that has never been restored is not a backup; it's hope.
5. Verify cron. Without cron running regularly, notifications, backups and queues stop silently.
6. Check the HTTPS certificate and its expiry date. Preferably with automatic renewal configured.
7. Review accounts with administrator role. Former scholarship students and former lecturers often remain there.
8. Confirm the site registration at moodle.org — that's what ensures you receive security alerts by email.
9. Check the mobile app web services. If they're enabled, the app is an entry point that also needs attention.
10. Record an owner and a monthly window. Without these two items on paper, the entire checklist becomes a snapshot — not a process.

What to do with this still in August

The window is short and the calculation is simple: a Moodle MAT or any other departmental Moodle stuck on 5.0 loses security support on 5 October 2026, and the details of the flaws fixed on 10 August become public this week. The priority order we suggest is to apply the current branch patch now, audit plugins and environment next, and only then plan the jump — ideally aiming for the 5.3 LTS in October.

I'm Cleverson Gouvêa, full-stack developer, Moodle certified and CTO of IEJUR. Since 2008, leading Agathas Web, I've operated EAD environments on Linux servers with Redis and I take care of exactly this type of orphaned installation: version upgrades, migration to the /public structure, infrastructure adjustments and consolidation of scattered instances. I've seen a 2016 Moodle in production with a plugin unmaintained since 2019 — the scenario is more common than it seems.

If your department's next step is to take the environment to the student's mobile phone, it's worth understanding the options first: we compare the official app and a custom app in Moodle Mobile App vs custom app, detail the process of publishing the Moodle app on Google Play and the App Store and show the real impact of push notifications on engagement. But none of that works well on an outdated base. The update comes first.

Want a diagnosis of your instance before October? Contact us — the initial audit costs nothing and the report is yours, regardless of whether you hire us or not.