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

If you have opened Moodle’s security report and seen a line called “XSS trusted users” with a number next to it, it sounds like an alarm. It is worth understanding, but it is not telling you that you have been hacked. It is telling you that some of your users hold capabilities that Moodle classifies as dangerous. This guide explains what that classification means, how to see which capabilities are risky, how to find who holds them, and how to bring the count down sensibly. Paths and behavior are for Moodle 4.5.

What “dangerous capability” actually means

In Moodle, every individual permission (every capability) can carry one or more risk flags. The risks are defined in core and there are six of them:

• RISK_XSS – the capability lets a user add content that then runs inside other people’s browsers (a cross-site scripting risk).
• RISK_CONFIG – the capability can change site configuration.
• RISK_PERSONAL – it can expose other users’ private data.
• RISK_MANAGETRUST – it can change trust settings.
• RISK_DATALOSS – it can cause permanent loss of data.
• RISK_SPAM – it can be used to send spam.

None of these are bad in themselves. An administrator genuinely needs them. The point of the flags is that capabilities carrying them should only ever sit with people you completely trust. The “XSS trusted users” security check simply counts how many users currently hold any RISK_XSS capability, on the principle that this set should be small and deliberate.

Where to see the risk flags on a role

Go to Site administration > Users > Permissions > Define roles and open a role. Next to each capability you will see small risk icons; hovering over one tells you which risk it represents. This is how you spot a role that has been granted more power than its name suggests, for example a “Helpdesk” or “Support” role that has quietly been given the ability to change site configuration or manage other users. That is exactly how sites end up over-exposed: a role accumulates permissions well beyond its purpose.

Pay particular attention to any role that applies to everyone, such as the default authenticated user role and the site home role. Every account inherits those, so a single risky capability there is handed to your entire user base at once.

Finding who actually holds a risky role

The question that matters in practice is not which roles are risky, but which people hold them. Two tools answer this:

• Check permissions (/admin/roles/check.php?contextid=1 at site level) shows the effective capabilities for a specific user.
• Assign roles on the role definition, or the participants and “Other users” lists in a context, show who is assigned a given role there.

If you want the full picture across the whole site in one query, the assignment data lives in the database. This SELECT lists every user who holds a role that includes at least one RISK_XSS capability:

SELECT DISTINCT u.id, u.username, r.shortname AS role
FROM mdl_role_assignments ra
JOIN mdl_user u ON u.id = ra.userid
JOIN mdl_role r ON r.id = ra.roleid
WHERE ra.roleid IN (
    SELECT DISTINCT rc.roleid
    FROM mdl_role_capabilities rc
    JOIN mdl_capabilities c ON c.name = rc.capability
    WHERE rc.permission = 1
      AND (c.riskbitmask & 4) = 4   -- 4 = RISK_XSS
)
ORDER BY role, u.username;

The bitmask values match the core constants: 1 = manage trust, 2 = config, 4 = XSS, 8 = personal, 16 = spam, 32 = data loss. Swap the value to audit a different risk. That result is your review list: for each person, ask whether they genuinely need this level of access.

The fix

There are two levers, and the right one depends on what you found:

1. Trim the role. If a role carries capabilities it should not, edit it under Define roles and remove them, especially from roles whose name implies a limited purpose.
2. Unassign the person. If the role is legitimately powerful but the wrong people hold it, remove those assignments.

Re-run the security check afterwards and the count comes down. The goal is not zero; your administrators legitimately need these powers. The goal is that every dangerous capability sits only with someone you actually trust, and that no everyone-role carries one.

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