CVE-2024-43437

What it actually does

Insufficient sanitization of user-supplied data during course or site restore operations permits persistent cross-site scripting payloads embedded in malicious backup archives to be stored and later executed in the context of other users' browsers.

Why it matters to the business

Attackers can hijack authenticated sessions, steal user data, or perform unauthorized actions inside the learning platform; the low exploitation probability and absence from known exploited lists reduce immediate urgency but still require prompt patching of any internet-facing or multi-tenant installations.

How an attack unfolds

An attacker creates or modifies a Moodle backup file containing unsanitized script content, uploads and restores the archive through the normal restore workflow, and the payload is persisted in the database so that subsequent users who view the restored content trigger script execution.

How to fix it

Upgrade Moodle to the commit aea9770cfc7d003a737f4899489d1e3982efe9ac or later; verify that the restore path applies the new sanitization logic before allowing untrusted backup files.

How to confirm the fix worked

Confirm the installed codebase contains commit aea9770cfc7d003a737f4899489d1e3982efe9ac, attempt a restore of a test backup containing known script markers, and verify that the markers are escaped or rejected in the resulting pages.

Typical attack path

1. Craft or tamper with a Moodle backup archive to include executable script in unsanitized fields
2. Obtain sufficient privileges to initiate a course or site restore
3. Perform the restore operation so the payload is written to the database without sanitization
4. Wait for or lure other users to interact with the restored content, triggering XSS

How to detect it

Review web-server and application logs for restore operations initiated by non-admin accounts, search database tables that store restored content for unexpected script tags, and monitor for new user sessions or actions originating from pages that were recently restored.

What your security team should do

• Apply the fixed commit to all Moodle instances within the next maintenance window
• Restrict restore permissions to trusted administrators until the patch is deployed
• Add automated scanning of uploaded backup archives for script patterns as a compensating control