Moodle security assessment

Why a Moodle security assessment matters for a self-hosted learning platform

A Moodle security assessment checks whether a self-hosted Moodle site is patched, configured and permissioned in a way that a compliance framework, a customer security review, a launch or an insurer can rely on. It covers the core version and its patch status, installed plugins, roles and capabilities, authentication methods and site configuration, and it tests the weaknesses those areas most often expose. If your request comes from an assessor or customer who has asked for evidence, the assessment should produce findings you can show them, along with the steps you took to close each one.

A Moodle site usually holds more personal data than its operators expect. It stores student identities, grades, course submissions, staff accounts and, often, assessment content and integrations with student information or single sign-on systems. Four risk categories drive most findings: core and plugins that lag behind security releases, roles that have accumulated capabilities beyond what their holders need, authentication settings that allow weak or legacy sign-in paths, and site configuration left at defaults or changed without review. Each of these can be checked against the site itself, not only against policy documents. Confirm with your team which plugins are installed, who holds the Manager and Teacher roles, and which authentication plugins are enabled before scoping the work.

Patch status deserves particular attention because Moodle handles disclosure in a deliberate order. Security reports go through a submission form triaged by Bugcrowd, and issues are disclosed only after a fix exists and registered Moodle sites have had time to upgrade or patch. Announcements appear in the moodle.org security news forum, so a site can be running a version with publicly known fixes without anyone on the team noticing. The assessor should compare your installed core and plugin versions against those announcements, and you should confirm with your hosting or support provider how quickly they apply Moodle security releases to your environment, since that timing sets how long a known issue stays open. Moodle's security process explains how the disclosure timeline works.

What can be in scope for a Moodle assessment

A Moodle assessment is only as useful as its boundaries, so the scope should be agreed in writing before testing starts. The items below are decisions to settle with the client, and each one changes the test plan, the accounts needed and the evidence the client receives.

Version and patch status

Record the exact Moodle core version and every point release applied since installation. Compare it with the security announcements posted to the moodle.org security news forum, and confirm which branches the vendor still supports. Agree whether the assessment checks only the running version or also the upgrade process and the staging copy used to test patches. Confirm any local core modifications, because they can block or complicate upgrades.

Core and third-party plugins

Inventory every plugin, including its version, source, install date and maintenance status. Third-party plugins often carry the highest risk because they may lack the same review as core code, and some may be unmaintained. Agree whether custom or locally written plugins are in scope, and whether the review covers code, configuration or both. Ask the client to provide the plugin list in advance so testing time is spent on what matters.

Roles and capabilities

Map the built-in roles and any custom roles, then review capability overrides at system, category and course levels. Decide which roles are tested, such as administrator, manager, teacher, student and guest, and whether custom roles that grant access to sensitive areas are included. Confirm whether the test checks that one role cannot reach another role's data, for example through course enrolment or group settings.

Authentication methods

Confirm which authentication methods are enabled on each site, such as manual accounts, LDAP, SAML, OAuth 2 or others. Each method has its own risks, including weak fallback logins, misconfigured identity provider trust, and account linking that can be abused. Agree whether the test covers password policy, lockout behavior, session handling and the admin login path. Confirm the identity provider's configuration is in scope or only the Moodle side.

Site configuration and hosting layers

Agree whether the assessment reviews site administration settings, the web server and TLS configuration, the database and the file storage. Items to confirm include HTTPS enforcement, exposed administration and cron paths, PHP settings, database network access, and permissions on the data directory. Backups are part of this layer, so confirm how they are stored and who can restore them. Each layer should be named in the scope so that gaps between the application team and the infrastructure team are not missed.

Rules of engagement

Agree that testing runs only against the client's own installation and that the client owns or controls every system in scope. Decide whether testing happens on staging, production or both, and what happens if production data is exposed during testing. Confirm whether authenticated testing is included, how many test accounts are provided per role, and who creates and removes them. Set the testing windows, the contact for emergencies and the rule for stopping tests that affect learners.

How a Moodle assessment runs, phase by phase

The sequence moves from agreed scope and version baseline to tested findings and a retest, so the client ends with a verified picture of its Moodle site and a record of what changed. Each phase closes with a defined output that the next phase depends on.

Agree scope and rules of engagement in writing
The DeployOpen team and the client agree in writing which Moodle sites, hosts, plugins, user roles and test accounts are in scope, which testing types are allowed (unauthenticated, authenticated, or both), and which activities are excluded, such as load testing or changes to live course data. The schedule follows from this scope, so a single site with a small plugin set takes less effort than a multi-site institution with many integrations. The phase closes when the signed scope document names the accounts to be provided and the contacts for emergencies.
Collect evidence on the running site
The team gathers the Moodle version and build, the PHP and database versions, the web server and TLS configuration, and the full list of installed plugins with their versions. The client provides administrator-level read access to the site configuration and the server, either directly or through a supervised review session. Where the client uses a managed or shared hosting arrangement, the team confirms which layers the client controls. The phase closes with a baseline inventory that the rest of the assessment checks against.
Check version and patch status against Moodle announcements
The team compares the running Moodle core and each plugin against the security announcements that Moodle publishes on its security news forum, and against the security process Moodle documents for how issues are fixed and disclosed. Moodle discloses security issues only after fixes are available and registered sites have had time to patch, so a site that lags behind a published fix is a measurable gap. The team also checks whether the installed branch is still receiving fixes. The phase closes with a list of unpatched items, each tied to the announcement it depends on.
Review plugins, roles and capabilities
The team reviews the installed plugins for their source, maintenance status and whether they are needed, since each plugin widens the code that runs on the site. It then reviews roles and capabilities, looking for custom roles that grant more than their purpose requires, broad rights given at system context instead of course context, and accounts that hold teacher or manager rights without a current need. The review is performed in the administration interface and with exported role definitions, so the findings can be reproduced. The phase closes with a role map and a plugin register marked for keep, review or remove.
Assess authentication and site configuration
The team checks the authentication methods enabled on the site, such as manual accounts, LDAP, OAuth 2 or SAML plugins, along with password policy, account lockout, session handling, and whether self-registration is enabled and controlled. Site configuration review covers HTTPS enforcement, cookie settings, debugging output, file upload restrictions, and the reachability of administrative paths from the internet. Where the client gives permission, the team confirms each setting against the live site rather than against documentation alone. The phase closes with a configuration review record that states, for each setting, the observed value and the expected value.
Test unauthenticated and authenticated access within scope
Within the agreed scope, the team tests what an anonymous visitor can reach, then tests with accounts at each agreed role level, such as student, teacher and manager, to confirm that access checks hold. The work follows the web application testing approach documented for this kind of site and avoids disruptive actions, using the test accounts the client supplied. Any action that could alter data or affect other users is performed only in a test course or staging copy that the client has agreed to. The phase closes with a log of test cases, their results and the evidence for each result.
Validate findings and rate their impact
Each candidate issue is reproduced by a second team member, checked against the affected version, and confirmed as a real weakness in the client's configuration rather than an expected behavior. The team records the affected component, the conditions needed, the likely impact, and a severity rating explained in plain terms. Findings that depend on administrator permissions are labeled as such, because Moodle's own security process treats some issues differently by permission level. The phase closes with a validated findings list that the client can prioritize.
Report findings and retest after remediation
The report sets out the scope, the method, the version baseline, each validated finding with its evidence and recommended fix, and a summary for the client's leadership. The client then fixes the findings and the team retests each one against the same evidence, recording whether it is closed, partly closed or still open. The remediation timeline is set by the client based on each finding's impact and priority, which is the approach CIS Controls v8.1 describes for penetration test findings. The phase closes with a retest record that the client can share with its auditor or customer.

Weakness categories we check in a Moodle site

Moodle publishes security fixes through its own release and security announcement channels, and a site that trails those releases carries known weaknesses for as long as it stays behind. Moodle discloses security issues only after fixes exist and registered sites have had time to upgrade or patch, so the public announcement starts the patching clock for every site that has not yet updated. A review measures how far the installed version sits from the fixes that have been published.

Core version against announcements: Compare the installed core version with the security announcements posted to the moodle.org security news forum and the fixes each one lists.
Support status of the branch: Confirm whether the installed branch still receives security fixes, and check its support dates with Moodle before the test is scoped.
Unapplied fixes: Look for security fixes that were released but never applied, including fixes that must be merged into a customized copy of core code.
Update process: Ask who approves an update, whether it is tested on a staging copy first, and how quickly past critical fixes reached production.

Record the installed version, the date of the last upgrade and the gap between each relevant announcement and the production update, using Moodle's security process guidance as the reference point.

How patch status is checked against Moodle security announcements

The first check is whether the installed Moodle core and every installed plugin match a version that Moodle's security process considers current. We record the exact core release from the site's version information, list each plugin with its installed version, and compare both against the security announcements posted to the moodle.org security news forum. Moodle's process works in a fixed order: a fix is made first, the issue is disclosed only after the fix exists, and registered sites are given time to upgrade or patch before the details are public. That order means a site that has not applied an announced fix is exposed to a problem that is already documented, so the gap between the installed version and the fixed version is the thing to measure, not whether anyone has proven an attack against this particular site.

A site that is behind on an announced fix is a finding in its own right, even without a demonstrated exploit path. We do not treat the announcement as a simple version match, though. Each advisory names the affected branches and releases, and some issues affect only specific plugins, settings or enabled features. The team reads each announcement against the installed core and plugin versions, confirms which fixes apply to the version in use, and notes where a fix is absent because the affected plugin is not installed or the feature is disabled. Those conclusions go into the assessment with the evidence for each, so the client can see why an item is open, closed or not applicable. Because announcement lists change, the list used in the assessment should be confirmed with Moodle directly before work begins and again before the report is issued. Ask Moodle for the current security announcements and the supported release branches, and compare them against the site's own upgrade history. The Moodle security process describes how reports and announcements are handled, which is the natural starting point for that confirmation. Clients should also ask who on their side will apply patches, how quickly a high-severity fix can be scheduled, and whether a staging copy is available to test upgrades before they reach production.

What drives the cost and duration of a Moodle assessment

This table lists the factors that change the effort behind a Moodle review, why each one matters, and how to keep scope efficient. Read it before requesting a quote, because the same drivers appear in the written scope that DeployOpen agrees with you before work starts. DeployOpen does not publish prices, so a quote follows from the scope you define.

Driver	Why it changes effort	How to keep scope efficient
Number of instances and environments	Each production, staging and test site needs its own version check, configuration review and sampling. Multi-site installs multiply that work.	Confirm which environments hold live data and which are representative copies. Assess production in depth and sample the rest.
Count and type of plugins	Each third-party plugin must be matched against its version, its maintainer's update status and any Moodle security announcement. Plugins with their own endpoints or data handling need extra review.	Provide a full plugin inventory with versions. Separate core, official and third-party plugins, and flag those with custom or local changes.
Roles, capabilities and authentication methods	Custom roles and overridden capabilities widen the permission matrix that must be tested. Each enabled authentication method, such as LDAP, SAML, OAuth 2.0 or manual accounts, adds its own login and session checks.	List custom roles, context overrides and enabled authentication plugins. Test only the methods that are live in production.
Authenticated testing depth	Testing as several roles, including teachers, managers and students, means repeating access-control checks per role. Deeper testing of course content, grading and file handling takes more time.	Agree the number of test accounts and the user journeys in writing. Start with the roles that hold sensitive data or administrative rights.
Custom code and theme modifications	Local plugins, theme overrides and changes to core files are not covered by the public advisory process, so they need source-level review and cannot be checked by version alone.	Provide a repository or archive of local code and a list of core file modifications. Exclude unchanged code from manual review.
Hosting complexity	On-premise, air-gapped and multi-tenant deployments add work on reverse proxies, database access, file storage, backup handling and network segmentation. Air-gapped sites also need offline reference material and a controlled test process.	Document the hosting model, network zones and any shared components before scoping. Confirm the tester's access route and any restrictions on tooling.
Retest scope	A retest of confirmed findings is usually smaller than the first assessment, but it grows if remediation changes configuration or code across several areas, or if fixes need a new Moodle version.	Ask for retesting to be included as a defined item with a set number of findings and a stated retest window.
Quote inputs to request	A quote follows from the written scope, so vague scopes produce wide ranges or later change requests.	Ask for the assumed environments, plugin and role counts, test accounts, hosting model, deliverables, retest terms and the timeline in writing.

What the client receives after a Moodle assessment

A Moodle assessment ends with a set of documents that serve different readers: the platform team, the security leadership, and the auditor or customer who asked for evidence. Each card below describes one deliverable and what to confirm about it before testing starts.

Executive summary and scope

The executive summary states the overall risk position of the Moodle site in plain terms for leadership, along with the number of findings by severity. The scope and method section records which hosts, Moodle version, plugins, roles, authentication methods and configuration areas were covered, what was excluded, and which testing approach was used. Ask for this section to match the agreed written scope exactly, so that gaps are visible to anyone reading it later.

Version and patch status table

This table compares the installed Moodle core release and each installed plugin against the Moodle security announcements that apply to them, and marks which fixes are missing. It shows how far the site lags behind published fixes, which is the question most auditors ask first. Confirm whether the table covers plugins as well as core, since plugin code is a frequent source of exposure.

Findings with severity and evidence

Each finding names the weakness category, the affected component, the severity rating and the evidence that supports it, such as a configuration value, a role assignment or a version comparison. Evidence is recorded so that the platform team can reproduce the check on its own, without the report containing exploit steps. Ask how severity is assigned and whether the tester will explain each rating in the report.

Remediation tied to upgrade paths

Remediation guidance is written against the Moodle upgrade path that applies to the site, including which core release or plugin version resolves each finding and what must be done before the upgrade, such as backups and plugin compatibility checks. Configuration fixes are listed separately with the setting to change and the expected effect. Ask for the remediation to name a target version rather than only saying to update.

Retest results

After the platform team applies fixes, a retest confirms which findings are closed, which remain open, and which were accepted as risk with a written reason. The retest is recorded as a separate, dated document so that the original report stays intact as a record of the state at testing time. Agree the retest window and any included effort in the written scope, since retesting is often priced separately.

Assessment letter and format limits

An assessment letter summarizes the scope, the testing period and the outcome for a customer's security review or an auditor's file. Auditors and customers generally accept a letter or report from a non-accredited tester only when its method and competence are clear, and they often decline a letter that claims certification or attestation, which only independent auditors and certification bodies can issue. DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications. Confirm the required format, wording and sign-off with the auditor or customer before testing starts.

How a Moodle assessment differs by hosting model

When Moodle runs in your own data center or a private cloud account, the assessor usually has direct network paths to the application, the database host and the web tier. The questions tend to center on how the site is reached from user networks, how quickly it is patched and how the team controls plugins and server settings.

Access: Testing usually starts from an agreed network position, such as an internal segment or VPN, plus the public listener if the site is internet-facing. Confirm which hostnames, reverse proxies and load balancers are in scope.
Testing windows: Active tests against a production site should avoid enrollment periods, assessment dates and exam sessions. Agree a window with the teaching operations owner and a freeze period before testing starts.
Data handling: Use dedicated test accounts instead of learner accounts. Confirm whether any staging copy of the database contains personal data and who may access it.
Evidence: Configuration exports, the installed Moodle version, the plugin inventory and web server settings can usually be collected directly with read-only access, which gives the auditor a verifiable baseline.

Before testing, confirm who owns the patching cadence and whether the installed version sits on a release line that still receives security fixes, as described in Moodle's security process.

What your team prepares before a Moodle assessment

Before any testing starts, the most useful thing your team can do is name the people who make decisions. Confirm a single technical owner for the Moodle site, a second contact for the hosting platform, and a named person who can approve changes or stop testing if the site shows signs of strain. Assessors need these contacts to resolve scope questions quickly, to confirm which plugins are live in production, and to agree who is informed if a finding suggests an active compromise. Also confirm who signs off the written rules of engagement, because that is the person who can authorize testing against accounts, data and integrations that other teams own.

Agree where testing happens. Testing against production is rarely the right default for a learning platform that holds grades, personal data and assessment records. Ask whether a staging copy exists, how closely it matches production in Moodle version, plugin set, authentication configuration and config.php settings, and whether it has been refreshed recently. If no staging copy exists, agree a test window with explicit start and end times, a change freeze for the period, and a rollback path. Confirm that the platform owner has tested their backup and restore process recently, because a configuration review sometimes requires temporary changes and a documented recovery point is the safety net for both sides.

Prepare test accounts for each role the site actually uses, not only the administrator and a student. Moodle's role and capability model means that a teacher, non-editing teacher, manager, course creator and authenticated user can each expose different gaps, and custom roles built by your team are often where the most useful findings sit. Ask for a role export and a list of users who hold site-level roles. Hosting and reverse proxy details matter as well: which web server or load balancer terminates TLS, which headers and paths are forwarded, where cron runs, and whether administrative paths are reachable from outside your network. Export the Moodle and plugin inventory with versions and the site's security announcements status, and confirm how the team tracks Moodle's security announcements so that the assessment compares your version against the published fixes rather than against memory.

Questions buyers ask about Moodle security assessments

What drives the cost of a Moodle security assessment?

The cost follows the written scope, and the biggest factors are how many sites, plugins and authentication methods are in play, how much custom code or theme work exists, and whether testing covers only configuration and version review or also active testing of roles and capabilities. A single production site with a standard plugin set and a clear admin inventory costs less to assess than a multi-site estate with custom plugins and several SSO integrations. Ask for a quote that lists each component separately: the version and patch review, the plugin inventory, the role and capability review, any active testing, the report, and any retest. Recurring costs, such as re-review after each Moodle security release or a retainer for continuous checks, should be quoted separately from the one-time assessment.

How long does a Moodle security assessment take?

Duration depends mainly on the size of the site, the number of plugins, the complexity of the authentication setup and how quickly the client can provide access and answers. Preparation, such as collecting the Moodle version, the plugin list, the configuration export and the role definitions, often moves the schedule more than the testing itself. Access approvals, change windows for any active testing, and the time needed to confirm findings against the site's own environment also add time. Ask the provider for a timeline that names the dates on which the client must deliver inputs and the point at which the draft report will arrive, so the schedule is agreed in writing before work starts.

Can our internal team run a Moodle security review without outside help?

Yes, many teams can perform a configuration review and a patch status check internally, using Moodle's own security announcements and the site's administration pages. What an internal review usually lacks is independence, a documented method that an auditor will accept, and time spent on active testing of roles, capabilities and authentication flows. Internal staff also tend to review the settings they manage every day, so they can miss assumptions that an outside tester challenges. A practical approach is to keep routine patch and plugin checks in-house and commission an external assessment for the areas where an independent view is required.

What does our team need to provide for the assessment?

The provider will usually need a named technical contact, the Moodle version and the list of installed plugins with their versions, read-only or supervised administrator access as agreed in scope, the authentication configuration, and a description of integrations such as SSO, LTI tools or external storage. Your team should also confirm the hosting model, backup and staging arrangements, and the change windows during which active testing is allowed. Confirm which environment the testing targets, since testing a staging copy that matches production is often the safer route. Agree in writing who approves each access request and who receives findings during the engagement.

Does the assessment include a retest of the findings?

Whether a retest is included depends on the signed scope, so ask for it explicitly rather than assuming it. A typical structure separates the initial assessment from a follow-up check that confirms whether each finding was fixed, and the follow-up is usually priced as its own line item. Ask the provider to state how many retest rounds are included, how fixes are verified, whether the retest uses the same method as the original work, and how findings that the client accepts as risk are recorded. Remediation timelines are a client decision, and frameworks such as CIS Controls v8.1 expect findings to be fixed within a timeline set by their impact and priority.

Will the report satisfy an auditor or a customer security review?

A report from an external provider is evidence for your auditor or customer, but it does not replace their judgment or issue any certification. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue the reports and attestations. Before commissioning the work, ask the auditor or customer which format, method and scope they expect, and ask the provider to map findings to the controls you need to demonstrate. A useful report names the Moodle version reviewed, the date of testing, the scope boundaries, the method, each finding with its evidence and severity, and the status of remediation.

Is it safe to test a production Moodle site?

Testing a production site can be done with controls, but it carries more operational risk than testing a staging copy, because active tests can affect users, grades, or course data. The safer approach is to test a staging environment that mirrors production in version, plugins and configuration, and to confirm any production checks in advance. Agree on backup verification, test accounts that do not hold real student or staff data, rate limits, change windows and a named contact who can halt activity. These conditions belong in the written scope, so both parties know what is permitted before testing begins.

How DeployOpen scopes, tests, reports and retests Moodle sites

DeployOpen runs Moodle security testing as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before any work starts. For a Moodle site, the written scope should name the exact Moodle version and installed plugins in play, the authentication methods to be tested, the roles and capabilities to be reviewed, whether the test includes the production site or a staging copy, and which hosting layers are in scope, such as the web server, database and file storage. Because the quote follows from that written scope, the more precisely the client defines these boundaries, the fewer surprises arise later. DeployOpen is a Chainscore Labs company. Beyond testing, it also implements and hardens self-hosted platforms inside the client's own infrastructure, so a Moodle finding can be fixed by the same team that tested it, with changes made in the client's environment. Ask the provider whether they will retest against the same version and plugin set, and whether fixes will be made by them or by your own administrators.

The deliverable should be a report the client can act on and hand to its own governance. Ask for findings that show the affected setting, role, plugin or configuration key, the evidence that confirmed the issue, and a remediation step specific to the client's Moodle version. Where a control matters to an external assessment, ask the provider to map findings to the relevant framework controls in plain terms. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so the test report is an input to their work, not a substitute for it. Confirm with your auditor in advance which evidence they will accept.

Retesting is where most of the value of an assessment is realized. Agree in the written scope whether one retest round is included, how long the client has to apply fixes, and which findings will be verified. Remediation timelines should follow the impact and priority of each finding, which is the approach CIS Controls v8.1 describes for penetration test findings under Safeguard 18.3. For ongoing needs, such as tracking new Moodle security announcements, reviewing plugin updates each cycle, or repeating the assessment after upgrades, DeployOpen offers retainers. Ask what the retainer covers, how announcements are monitored and how quickly the provider will assess a new release. Also confirm who holds the administrator credentials used during testing and how they are revoked afterwards.