What Moodle’s “Dangerous Capabilities” Warning Means, and How to Fix It

You opened Site administration > Reports > Security overview, and one row is sitting on a yellow Warning: “XSS trusted users”, with a number next to it. It reads like an alarm. It is not. Nobody has been hacked, and nothing is broken.

That row is a trust roster. It tells you how many people on your site hold a permission powerful enough that, in the wrong hands, it could be misused. Your job is not to make the number zero. Your job is to look at the list and confirm that everyone on it is someone you actually trust. This guide walks through exactly how to read that warning and act on it, step by step, using only the Moodle admin screens. No database queries, no command line. Paths and behavior are for Moodle 4.5.

Prefer to watch? Here is a short walkthrough of reading and acting on the dangerous capabilities warning:

What the warning actually means

Every permission in Moodle (every capability) can carry one or more risk flags. They are advisory labels, not faults. There are six:

• XSS – the user can submit content that Moodle does not clean, such as HTML with active scripting or unchecked files. This is the one the “XSS trusted users” check counts.
• Configuration – the user can change site-wide settings.
• Personal – the user can reach other people’s private data.
• Spam – the user can put content in front of others, or message them.
• Data loss – the user can destroy large amounts of data that is hard to recover.
• Manage trust – the user can manage other users’ trust settings.

A capability flagged XSS is not a vulnerability. It is simply powerful: anyone who can author rich content (paste HTML, embed media, restore a course, manage roles) can in principle insert a script. That is normal and necessary. The point of the flag is so you can reason about who holds that power.

The most useful fact to keep in mind is how Moodle assigns these risks by default:

• Guest holds capabilities with no risk at all.
• Student adds Spam.
• Teacher adds Personal and XSS.
• Manager and Administrator effectively hold everything.

So your administrators, managers, and teachers are supposed to be on the XSS list. A non-empty list is the correct, healthy state. The warning is really one question: is everyone here someone I trust to post rich content?

Step 1: Read the list

Go to Site administration > Reports > Security overview and click XSS trusted users (or More info on that row).

Moodle now shows you every user who holds an XSS-flagged capability, anywhere on the site, each name linked to their profile. The page states the task plainly: verify the list and make sure you trust these people completely. Read the names. This is the audit.

Step 2: Decide who belongs

For each person, ask one question: should this account be able to author rich content, manage roles, or restore courses?

• Expected, leave them alone: administrators, managers, teachers, course creators, and any content-author role you deliberately created.
• Investigate: an account that should never author content (a plain learner, a generic “info” or service account), an unfamiliar name, or anything that looks automated or left over.

There is also a list-length signal. If the roster is dramatically longer than the number of staff who should have content power, a risky capability has almost certainly leaked into a role that is handed to many people at once, or a staff role has been assigned far too broadly. Hold that thought for Step 5.

Step 3: Find out why a user is on the list

This is the step most write-ups skip, because Moodle has no single screen that says “this user is risky because of capability X in role Y.” You assemble it from two screens, and it takes about thirty seconds per person.

From the list in Step 1, click the user’s name to open their profile, then go to Preferences > This user’s role assignments (under the Roles heading).

This page shows every role the user holds and the exact context for each one: system, a category, or a single course. It is where the cause usually jumps out, for example a support-style or helpdesk-style role assigned at system level, a Teacher or Manager role assigned site-wide instead of inside one course, or a custom role that grants far more than its name suggests.

A teacher assigned inside one course is exactly where they should be. A “support” role sitting at the top, system level, is the kind of thing this audit exists to catch.

Step 4: Confirm which capability is responsible

Open the role you just identified: Site administration > Users > Permissions > Define roles, then open that role.

On the capability table, the Risks column on the right shows a small icon against every capability that carries a risk. Hover an icon to see its label; the one marked XSS risk is your confirmation that this is what put the user on the list. Reading down that column tells you, at a glance, how much power the role really grants, which is often far more than its name implies.

If you would rather work the other way around, Site administration > Reports > Capability overview lets you pick a specific capability and see which roles grant it across the whole site. That is the fastest way to answer “which roles hand out this exact permission?”

Step 5: Fix it the right way

You have three clean options. Choose by what is actually wrong, and follow the principle of least privilege: give each person the least power that lets them do their job.

1. The person should not have that power. Remove them from the role, or narrow the assignment to the correct context. You can do this from the user’s role-assignments page or under the role’s Assign roles tab.
2. The role should not grant that capability. Edit the role (Define roles > [role] > Edit) and set the offending capability to Not set or Prevent, then save. This affects everyone who holds that role, so make sure none of them need it.
3. The capability is on a role given to everyone. This is the most common cause of a bloated list, and the most urgent. Check the Authenticated user, Guest, and Front page roles first: a single risky capability there is handed to your entire user base at once. These roles should never carry a dangerous capability.

One thing not to do: do not strip XSS capabilities from your standard Teacher role just to clear the warning. Teachers are on the list by design, and removing those capabilities breaks legitimate content authoring. If a particular teacher should be more limited, narrow where they are assigned rather than rewriting the shipped role. Editing default roles globally also wipes any course-level overrides your teachers rely on, so prefer a context-specific override or a purpose-built custom role.

Step 6: Verify, then re-check

Confirm the change did what you intended before you move on. In the relevant context (a course’s Participants > Permissions > Check permissions, or the system-level Check permissions screen), look up the user and confirm they can, or can no longer, do the thing you changed. This shows you the computed result rather than your assumption of it.

Then re-run Reports > Security overview. The XSS trusted users count should now contain only people you trust. Again: the target is not zero. The target is no surprises.

A note on “trusted content”

If you want to understand why XSS is a risk category at all, it comes down to how Moodle cleans HTML. By default Moodle strips active content from what users submit. There is an optional setting, Enable trusted content (under Site administration > Security), that, together with the moodle/site:trustcontent capability, lets named users save HTML that bypasses that cleaning.

It is off by default, and that is the right default for almost everyone. Leave it off unless you have a concrete reason to turn it on, and if you do, grant moodle/site:trustcontent to the smallest, most trusted group possible, because it widens exactly the list you just audited. For extra hardening in the other direction, the $CFG->forceclean setting forces content cleaning everywhere.

The same habit covers the whole report

The XSS trusted users check is one of several access checks in the Security overview, alongside Administrators, Guest role, Default user role, Front page role, and Backup data access risk. They all answer the same kind of question: are these settings, and these people, what I expect? Treat the security report as a periodic review rather than a one-time cleanup, and run through it after any change to roles or permissions.

Quick checklist

1. Reports > Security overview > XSS trusted users: read the list.
2. Tick off the people who should be there (admins, managers, teachers, content authors).
3. For anyone who looks wrong: Profile > Preferences > This user’s role assignments to find the role and context.
4. Define roles > [role]: read the Risks column to confirm the capability, or use the Capability overview report.
5. Fix by least privilege: unassign the person, narrow the context, or prevent the capability. Check blanket roles (Authenticated user, Guest, Front page) first.
6. Check permissions to verify, then re-run the Security overview. Aim for “only trusted people”, not zero.

Solin specializes in Moodle role and permission security. Contact us for a roles and capabilities audit.