Mahara before 25.04.5 and 26.04.0 is vulnerable in the Text block/section functionality when a call is crafted in a certain way that allows it to recall the backed-up content from another Text section.
Mahara before 25.04.5 and 26.04.0 is vulnerable to artefacts being accessible to others under certain circumstances when the file path to an artefact in a page is manipulated.
Mahara before 25.04.5 and 26.04.0 is vulnerable to unauthorized access to internal accounts via Learning Tools Interoperability (LTI) under certain circumstances. This applies to LTI 1.1 and LTI 1.3 Advantage.
Mahara 21.04 before 21.04.7, 21.10 before 21.10.5, 22.04 before 22.04.3, and 22.10 before 22.10.0 potentially allow a PDF export to trigger a remote shell if the site is running on Ubuntu and the flag -dSAFER is not set with Ghostscript.
In Mahara 21.04 before 21.04.7, 21.10 before 21.10.5, 22.04 before 22.04.3, and 22.10 before 22.10.0, embedded images are accessible without a sufficient permission check under certain conditions.
In Mahara 18.10 before 18.10.5, 19.04 before 19.04.4, and 19.10 before 19.10.2, file metadata information is disclosed to group members in the Elasticsearch result list despite them not having access to that artefact anymore.
In Mahara 18.10 before 18.10.5, 19.04 before 19.04.4, and 19.10 before 19.10.2, certain personal information is discoverable inspecting network responses on the 'Edit access' screen when sharing portfolios.
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.
Multiple cross-site scripting (XSS) vulnerabilities in Mahara 1.0 before 1.0.10 and 1.1 before 1.1.2 allow remote attackers to inject arbitrary web script or HTML via a (1) profile and (2) blog, a different vulnerability than CVE-2009-0487.
Cross-site scripting (XSS) vulnerability in Mahara before 1.0.9 allows remote attackers to inject arbitrary web script or HTML via a crafted forum post.
Mahara before 1.5.13, 1.6.x before 1.6.8, and 1.7.x before 1.7.4 does not properly restrict access to folders, which allows remote authenticated users to read arbitrary folders (1) by leveraging an active folder tab loaded before permissions were removed or (2) via the folder parameter to artefact/file/groupfiles.php.
Mahara before 1.5.12, 1.6.x before 1.6.7, and 1.7.x before 1.7.3 does not properly restrict access to artefacts, which allows remote authenticated users to read arbitrary artefacts via the (1) artefact id in an upload action when creating a journal or (2) instconfartefactidselected[ID] parameter in an upload action when editing a block.
Cross-site scripting (XSS) vulnerability in Mahara before 1.5.12, 1.6.x before 1.6.7, and 1.7.x before 1.7.3 allows remote attackers to inject arbitrary web script or HTML via the Host header to lib/web.php.
Mahara before 1.5.12, 1.6.x before 1.6.7, and 1.7.x before 1.7.3 does not properly prevent access to blocks, which allows remote authenticated users to modify arbitrary blocks via the bock id in an edit request.
SQL injection vulnerability in lib/user.php in mahara 1.0.4 allows remote attackers to execute arbitrary SQL commands via a username.
Mahara before 25.04.2 and 24.04.11 are vulnerable to displaying results that can trigger XSS via a malicious search query string. This occurs in the 'search site' feature when using the Elasticsearch7 search plugin. The Elasticsearch function does not properly sanitize input in the query parameter.
In Mahara before 24.04.10 and 25 before 25.04.1, an institution administrator or institution support administrator on a multi-tenanted site can masquerade as an institution member in an institution for which they are not an administrator, if they also have the 'Site staff' role.
The getdatarootimagepath function in lib/file.php in Mahara before 1.4.1 does not properly validate uploaded image files, which allows remote attackers to cause a denial of service (memory consumption) via a (1) large or (2) invalid image.
Mahara before 1.4.1, when MNet (aka the Moodle network feature) is used, allows remote authenticated users to gain privileges via a jump to an XMLRPC target.
Cross-site scripting (XSS) vulnerability in the resume blocktype in Mahara before 1.0.13, and 1.1.x before 1.1.7, allows remote attackers to inject arbitrary web script or HTML via unspecified vectors.
Mahara 1.1 before 1.1.5 does not apply permission checks when saving a view that contains artefacts, which allows remote authenticated users to read another user's artefact.
Multiple cross-site scripting (XSS) vulnerabilities in Mahara 1.0 before 1.0.12 and 1.1 before 1.1.5 allow remote attackers to inject arbitrary web script or HTML via unknown vectors.
Cross-site request forgery (CSRF) vulnerability in Mahara before 1.4.1 allows remote attackers to hijack the authentication of administrators for requests that add a user to an institution.
The "Reply to message" feature in Mahara 1.3.x and 1.4.x before 1.4.1 allows remote authenticated users to read the messages of a different user via a modified replyto parameter.
Multiple cross-site scripting (XSS) vulnerabilities in Mahara 1.0.x before 1.0.11 and 1.1.x before 1.1.3 allow remote attackers to inject arbitrary web script or HTML via (1) the introduction field in a user profile or (2) an arbitrary text block in a user view.
Cross-site Scripting (XSS) in Mahara before 1.5.9 and 1.6.x before 1.6.4 allows remote attackers to inject arbitrary web script or HTML via the TinyMCE editor.
Mahara 16.10 before 16.10.7 and 17.04 before 17.04.5 and 17.10 before 17.10.2 have a Cross Site Scripting (XSS) vulnerability when a user enters invalid UTF-8 characters. These are now going to be discarded in Mahara along with NULL characters and invalid Unicode characters. Mahara will also avoid direct $GET and $POST usage where possible, and instead use paramexists() and the correct param() function to fetch the expected value.
Mahara 16.10 before 16.10.7, 17.04 before 17.04.5, and 17.10 before 17.10.2 are vulnerable to being forced, via a man-in-the-middle attack, to interact with Mahara on the HTTP protocol rather than HTTPS even when an SSL certificate is present.
Mahara 15.04 before 15.04.14 and 16.04 before 16.04.8 and 16.10 before 16.10.5 and 17.04 before 17.04.3 are vulnerable to a user submitting potential dangerous payload, e.g. XSS code, to be saved as their name in the usrregistration table. The values are then emailed to the the user and administrator and if accepted become part of the new user's account.
Mahara 17.04 before 17.04.8 and 17.10 before 17.10.5 and 18.04 before 18.04.1 can be used as medium to transmit viruses by placing infected files into a Leap2A archive and uploading that to Mahara. In contrast to other ZIP files that are uploaded, ClamAV (when activated) does not check Leap2A archives for viruses, allowing malicious files to be available for download. While files cannot be executed on Mahara itself, Mahara can be used to transfer such files to user computers.