Mahara Mahara 1.9.5

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 21.04 before 21.04.6, 21.10 before 21.10.4, and 22.04.2, files can sometimes be downloaded through thumb.php with no permission check.

In Mahara before 20.10.5, 21.04.4, 21.10.2, and 22.04.0, a site using Isolated Institutions is vulnerable if more than ten groups are used. They are all shown from page 2 of the group results list (rather than only being shown for the institution that the viewer is a member of).

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.

Mahara before 20.10.5, 21.04.4, 21.10.2, and 22.04.0 is vulnerable to Cross Site Request Forgery (CSRF) because randomly generated tokens are too easily guessable.

In Mahara 21.04 before 21.04.3 and 21.10 before 21.10.1, portfolios created in groups that have not been shared with non-group members and portfolios created on the site and institution levels can be viewed without requiring a login if the URL to these portfolios is known.

In Mahara 20.10 before 20.10.4, 21.04 before 21.04.3, and 21.10 before 21.10.1, the names of folders in the Files area can be seen by a person not owning the folders. (Only folder names are affected. Neither file names nor file contents are affected.)

In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, the account associated with a web services token is vulnerable to being exploited and logged into, resulting in information disclosure (at a minimum) and often escalation of privileges.

In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, exported CSV files could contain characters that a spreadsheet program could interpret as a command, leading to execution of a malicious string locally on a device, aka CSV injection.

In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, exporting collections via PDF export could lead to code execution via shell metacharacters in a collection name. Additional, in Mahara before 20.10.4, 21.04.3, and 21.10.1, exporting collections via PDF export could cause code execution

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.

In Mahara before 20.04.5, 20.10.3, 21.04.2, and 21.10.0, adjusting the path component for the page help file allows attackers to bypass the intended access control for HTML files via directory traversal. It replaces the - character with the / character.

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.

In Mahara 19.04 before 19.04.5 and 19.10 before 19.10.3, account details are shared in the Elasticsearch results for accounts that are not accessible when the config setting 'Isolated institutions' is turned on.

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.

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.

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. A site administrator can suspend the system user (root), causing all users to be locked out from the system.

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.

Mahara 17.04 before 17.04.8 and 17.10 before 17.10.5 and 18.04 before 18.04.1 are vulnerable to the browser "back and refresh" attack. This allows malicious users with physical access to the web browser of a Mahara user, after they have logged in, to potentially gain access to their Mahara credentials.

Mahara 17.04 before 17.04.8 and 17.10 before 17.10.5 and 18.04 before 18.04.1 are vulnerable to mentioning the usernames that are already taken by people registered in the system rather than masking that information.

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.

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 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 param_exists() and the correct param_*() function to fetch the expected value.