Hacked Moodle: Student Data and Course Integrity

By Glenn Lyvers · Updated September 21, 2026 · 4 min read

A Moodle compromise is two problems at once. There is the ordinary technical one of cleaning an infected PHP application, and there is the fact that the application holds records about students — often minors, often including assessment data. The second usually determines how seriously the incident has to be handled, regardless of how modest the malware turns out to be.

How Moodle sites get compromised

Outdated core is the leading cause. Moodle publishes security advisories on a regular schedule and institutions frequently run behind, sometimes by whole versions, because upgrades are disruptive in term time. That gap is where most compromises come from.

After that: third-party plugins, of which a typical institutional Moodle has many and which vary widely in maintenance; weak or reused administrator credentials; and the specific risk of a platform with a large number of accounts, since one compromised teacher or administrator account is enough. Self-registration left open without moderation is worth checking too.

Where to look

The moodledata directory is the critical one. It holds uploaded files, caches and session data, and on a correctly configured installation it sits outside the web root entirely. If it is web-accessible, that is both a likely entry point and a data exposure in its own right — check by requesting a known path within it.

Then: the plugin directories for code you did not install, core files compared against a clean copy of your exact version, and the database for injected content. Check for administrator accounts you did not create and for existing accounts that have been quietly promoted, since Moodle's role system makes a permission change less visible than a new account.

The data question comes first

Before you get absorbed in the cleanup, establish what was reachable. Student records, contact details, grades and assessment submissions all live in that database, and if an attacker had database access the working assumption is that they had all of it.

That is very likely a notifiable data breach, and where students are minors the obligations and the sensitivity are both higher. Your institution probably has a data protection officer or equivalent, and they need to know now rather than after the technical work is finished — notification clocks generally start from awareness, not from resolution. My guide on breach notification obligations covers the framework.

Academic integrity

This is the consideration that does not arise on other platforms. If someone had administrative access, grades could have been altered and submissions tampered with, and that is a question your institution will need answered rather than assumed.

Moodle keeps detailed logs of user actions, and they are genuinely good. Review grade change history and administrative actions over the compromise window. Even where nothing was altered, being able to demonstrate that from the logs is worth the effort, because the alternative is uncertainty about every result in the affected period.

Cleaning it

Preserve evidence first, then update core to a supported, patched version, reinstall plugins from official sources, and remove anything you cannot account for. Sweep the database for injected content, delete unauthorised accounts, and review role assignments and permission definitions rather than only the user list.

Purge all caches afterwards, since Moodle caches heavily and stale cached content is a common source of confusion about whether a cleanup worked. Then rotate the database password, all administrator passwords, and any integration credentials for authentication providers, enrolment plugins or external tools.

Afterwards

Get onto a supported version and stay there, with a maintenance window schedule that allows security updates to be applied promptly rather than deferred to the next quiet period. Remove plugins nobody uses. Put two-factor authentication on administrator accounts, and review who holds elevated roles — institutional Moodles accumulate privileged accounts over years.

Confirm moodledata is outside the web root and not reachable. Then force a password reset across accounts, which is disruptive at scale but appropriate when the user table was readable. If you want the technical side handled properly while your institution deals with the data and integrity questions, that is work I take on — see the platforms I clean.

Common questions

Where should the moodledata directory be?

Outside the web root, so it is not reachable by URL. It holds uploaded files, caches and session data. If you can request a path inside it from a browser, that is both a probable entry point and a data exposure in itself, and it should be corrected immediately.

Is a Moodle compromise a reportable data breach?

Very likely. The database holds student records, contact details, grades and submissions, and if an attacker had database access the working assumption is that all of it was reachable. Where students are minors, both the obligations and the sensitivity are higher. Involve your data protection officer immediately.

Could grades have been changed?

If someone had administrative access, yes, and it is a question that needs answering rather than assuming. Moodle's logging is detailed — review grade change history and administrative actions across the compromise window. Being able to demonstrate nothing changed is as valuable as finding that something did.

Why does injected content persist after I clean the files?

Usually Moodle's caching. It caches heavily, so content generated while the site was infected can continue being served after the source is clean. Purge all caches after cleaning, then verify again before concluding the cleanup failed.

How do I check for unauthorised access after cleanup?

Audit user accounts for additions, but also review role assignments and permission definitions — promoting an existing account is quieter than creating a new one. Then force a password reset across accounts, since the user table was readable if the database was.