This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Mahara
Mahara before 20.10.5, 21.04.4, 21.10.2, and 22.04.0 allows stored XSS when a particular Cascading Style Sheets (CSS) class for embedly is used, and JavaScript code is constructed to perform an action. (2022-04-28, CVE-2022-29584)
In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, certain tag syntax could be used for XSS, such as via a SCRIPT element. (2021-11-02, CVE-2021-43265)
Catalyst IT Ltd Mahara CMS v19.10.2 was discovered to contain multiple cross-site scripting (XSS) vulnerabilities in the component groupfiles.php via the Number (Nombre) and Description (Descripción) parameters. (2021-10-22, CVE-2020-23052)
In Mahara 19.04 before 19.04.6, 19.10 before 19.10.4, and 20.04 before 20.04.1, certain places could execute file or folder names containing JavaScript. (2020-08-07, CVE-2020-15907)
An issue was discovered in Mahara 17.10 before 17.10.8, 18.04 before 18.04.4, and 18.10 before 18.10.1. The collection title is vulnerable to Cross Site Scripting (XSS) due to not escaping it when viewing the collection's SmartEvidence overview page (if that feature is turned on). This can be exploited by any logged-in user. (2019-05-07, CVE-2019-9709)
Mahara 16.10 before 16.10.9 and 17.04 before 17.04.7 and 17.10 before 17.10.4 are vulnerable to bad input when TinyMCE is bypassed by POST packages. Therefore, Mahara should not rely on TinyMCE's code stripping alone but also clean input on the server / PHP side as one can create own packets of POST data containing bad content with which to hit the server. (2018-04-09, CVE-2018-6182)
Why Cross-site Scripting can be dangerous
Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.
The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:
https://server.com/confirmation?message=Transaction+Complete
what results in:
<span>Confirmation: Transaction Complete</span>
In that case the message can be modified to become a valid Javascript code, e.g.:
https://server.com/confirmation?message=<script>dangerous javascript code here</script>
and it will be executed locally by the user's browser with full access to the user's personal application/browser data:
<span>Confirmation: <script>dangerous javascript code here</script></span>