CVE-2021-26812

What it actually does

This vulnerability is a reflected cross-site scripting flaw in the Jitsi Meet plugin for Moodle, affecting versions 2.7 through 2.8.3. The vulnerable sessionpriv.php module reflects attacker-controlled input into an application response without sufficient output encoding or sanitization. A remote unauthenticated attacker can craft a malicious URL that, when opened by a victim, causes JavaScript to execute in the victim’s browser in the security context of the Moodle/Jitsi plugin page. Because exploitation requires user interaction, the attacker must convince a user to click or visit the crafted link. Successful exploitation can allow theft of session-related data accessible to JavaScript, unauthorized actions performed as the victim, phishing overlays, content manipulation, or redirection to attacker-controlled sites. The CVSS scope change reflects that the browser-executed script can cross trust boundaries between attacker content and the legitimate application context.

Why it matters to the business

If exploited, this flaw can let an attacker abuse trusted Moodle/Jitsi pages to target users, steal sensitive information exposed to the browser, or perform actions as the victim. The operational risk is highest for organizations using Moodle with the affected Jitsi Meet plugin for online learning, meetings, or collaboration, because users may trust links that appear to belong to the legitimate learning platform. Although this issue is not listed in CISA KEV and is not known to be ransomware-linked, the EPSS score is very high and exploit maturity is reported as weaponized, so internet-facing deployments and user populations that commonly receive meeting links should treat remediation as urgent.

How an attack unfolds

An attacker first identifies a Moodle deployment using the affected Jitsi Meet plugin version. The attacker then crafts a URL targeting the plugin’s sessionpriv.php module with a malicious JavaScript payload embedded in a parameter or reflected portion of the request. The attacker delivers the URL through phishing email, chat, course content, forum posts, calendar invitations, or other social channels. When a logged-in user clicks the link, the Moodle/Jitsi page renders a response containing the attacker-supplied script. The browser executes that script as if it came from the trusted Moodle site. From there, the attacker may read browser-accessible data, alter page content, redirect the user, present a fake login prompt, or submit requests using the victim’s authenticated session, subject to browser protections and application authorization controls.

How to fix it

Upgrade the Jitsi Meet plugin for Moodle to a version newer than the affected 2.7 through 2.8.3 range, using the latest version available from the official Moodle plugin repository or vendor-maintained source. If an immediate upgrade is not possible, disable or remove the Jitsi Meet plugin until it can be updated. Apply defense-in-depth controls including strict output encoding, input validation, and a Content Security Policy that limits inline script execution and restricts script sources. Review Moodle permissions to reduce the impact of actions performed by compromised user sessions. Ensure session cookies use HttpOnly, Secure, and SameSite attributes where compatible, although these do not replace patching. Avoid relying on web application firewall filtering as the sole mitigation because reflected XSS payloads can often be obfuscated.

How to confirm the fix worked

Confirm the installed Jitsi Meet plugin version in Moodle and verify it is not version 2.7, 2.8, 2.8.1, 2.8.2, or 2.8.3. Review plugin inventory from the Moodle administration interface, filesystem metadata, package manifests, or deployment records. Test the vulnerable sessionpriv.php endpoint in a non-production or authorized environment with benign XSS probes and confirm the payload is encoded or rejected rather than executed. Validate that browser developer tools do not show execution of injected script when visiting crafted test URLs. Confirm that Content Security Policy and cookie security attributes are applied where feasible. Re-scan externally exposed Moodle instances and verify that the Jitsi plugin endpoint is either updated, inaccessible where not required, or removed.

Typical attack path

1. Identify a Moodle site using the vulnerable Jitsi Meet plugin version 2.7 through 2.8.3.
2. Craft a malicious URL that targets the Jitsi plugin sessionpriv.php module and includes JavaScript payload content.
3. Send the crafted URL to a target user through phishing, chat, learning-platform messages, shared meeting links, or embedded course content.
4. Wait for the victim to open the link in a browser, preferably while authenticated to the Moodle site.
5. Trigger execution of attacker-controlled JavaScript in the trusted application context.
6. Use the script to steal browser-accessible data, manipulate the page, redirect the user, or perform actions available to the victim’s session.

How to detect it

To determine whether exploitation has already occurred, review HTTP access logs from web servers, reverse proxies, CDN/WAF platforms, and Moodle application logs for requests to the Jitsi plugin’s sessionpriv.php module containing script tags, JavaScript URI schemes, encoded HTML, event-handler attributes, or suspicious redirect destinations. Pay particular attention to requests followed by unusual Moodle activity from the same user session or IP, such as profile changes, new content creation, role or enrollment changes, administrative actions, or authentication anomalies. Inspect phishing reports, email security logs, chat messages, and learning-platform posts for links to sessionpriv.php with long or encoded query strings. Browser-side XSS often leaves limited server-side evidence, so correlate URL clicks, referrers, user-agent strings, and subsequent account activity. If web security tooling is available, search for blocked or allowed XSS signatures involving the Moodle Jitsi plugin path. For endpoint/browser telemetry, look for users visiting suspicious sessionpriv.php URLs followed by navigation to unfamiliar domains, credential submission pages, or unexpected downloads.

• /mod/jitsi/sessionpriv.php
• sessionpriv.php
• sessionpriv.php?
• %3Cscript
• <script
• %3C/script%3E
• </script>
• javascript:
• %6a%61%76%61%73%63%72%69%70%74%3a
• onerror=
• onload=
• onclick=
• document.cookie
• document.location
• window.location
• eval(
• alert(
• prompt(
• confirm(
• String.fromCharCode
• <img
• %3Cimg
• <svg
• %3Csvg
• %3Ciframe
• %3Ciframe
• /sessionpriv.php?

What your security team should do

• Inventory all Moodle deployments and identify any use of the Jitsi Meet plugin, especially internet-facing instances.
• Prioritize upgrading or disabling Jitsi Meet plugin versions 2.7 through 2.8.3 because exploit maturity is reported as weaponized and EPSS is very high.
• Search web access logs for suspicious requests to sessionpriv.php containing script-like strings, URL-encoded payloads, event handlers, or redirects.
• Hunt for phishing messages or platform content containing links to the vulnerable endpoint with encoded parameters or JavaScript-like content.
• Deploy or tune WAF/SIEM detections for XSS payloads targeting the Jitsi plugin path, but treat detection as compensating control only.
• Review Moodle user activity around suspicious requests for unexpected profile changes, content edits, enrollment changes, or administrative actions performed shortly after link clicks.
• Ensure incident responders preserve web access logs, Moodle application logs, reverse proxy logs, and authentication logs for the period surrounding suspicious activity.