Moodle CVE-2026-102581

Exploitation requires an authenticated Moodle account with permission to create forum posts (PR:L) - typically any enrolled student or participant - because the payload is stored via a forum post. Execution additionally requires a second user to view the affected forum post (UI:R), so the attack is not self-contained and depends on victim interaction. The flaw is in the templates that render forum posts, so it affects standard forum functionality rather than a non-default feature; any Moodle instance running the forum module and an unpatched version is exposed. Limiting factors: authentication, required victim viewing action, and impact confined to the victim's browser session (partial confidentiality/integrity, no availability).

This is a genuine but moderate-severity issue, not an urgent one. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N, base 4.6) accurately reflects a stored XSS that requires an authenticated forum-posting account (PR:L) and a victim who views the malicious post (UI:R), with limited confidentiality and integrity impact and no availability impact. There is no EPSS score, no CISA KEV listing, and no public exploit provided, so exploitation status is: no public exploit identified at time of analysis. No SSVC decision data was supplied. The one signal-conflict worth flagging: the vendor scored scope as unchanged (S:U), but stored XSS that runs in another user's authenticated session arguably crosses a security boundary (S:C), which would raise the score - I reflect this in my own assessment below. Overall this is a real-priority-but-low-urgency defect: widely deployed platform (Moodle) but constrained by authentication, required victim interaction, and only partial C/I impact. It should be patched on a normal cadence rather than emergency-escalated.

An attacker with a normal authenticated Moodle account (e.g., an enrolled student) crafts a forum post containing malicious markup that the forum-display templates fail to escape. When a teacher or another student opens the discussion, the injected JavaScript executes in their browser under their Moodle session, allowing session-token theft, CSRF-style actions, or content manipulation. No public proof-of-concept is provided.