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 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.

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.

An issue was discovered in Mahara before 18.10.0. It mishandled user requests that could discontinue a user's ability to maintain their own account (changing username, changing primary email address, deleting account). The correct behavior was to either prompt them for their password and/or send a warning to their primary email address.