Nishacid

**Name of the Vulnerable Software and Affected Versions** YesWiki versions up to and including 4.4.5 **Description** The vulnerability allows any end-user to craft a DOM based XSS on all of YesWiki's pages, which is triggered when a user clicks on a malicious link. This issue makes use of the search by tag feature, where if a tag doesn't exist, it is reflected on the page and isn't properly sanitized on the server side. This enables a malicious user to generate a link that will trigger an XSS on the client's side when clicked, potentially leading to account takeover, modification of pages, comments, permissions, extraction of user data, and impacting the integrity, availability, and confidentiality of a YesWiki instance. **Recommendations** For versions up to and including 4.4.5, update to version 4.5.0 or later, which contains a patch for the issue. As a temporary workaround, consider sanitizing the tag names when created and looked for, to prevent client-side code execution. Implement a stronger password reset mechanism, such as not showing a password reset link to an already logged-in user, generating a password reset link when a reset is requested by a user and only sending it by mail, and adding an expiration date to the token. Consider implementing a strong Content Security Policy to mitigate other XSS sinks.

**Name of the Vulnerable Software and Affected Versions** YesWiki versions up to and including 4.4.5 **Description** The vulnerability allows an authenticated user with rights to edit or create a page or comment to trigger a stored XSS attack, which can be reflected on any page where the resource is loaded. This issue utilizes the content editing feature, specifically the `{{attach}}` component, which permits users to attach files or media to a page. If the resource in the `file` attribute does not exist, the server generates a file upload button containing the filename, enabling malicious users to steal accounts, modify pages, comments, and permissions, and extract user data like emails. **Recommendations** For versions up to and including 4.4.5, update to version 4.5.0, which contains a patch for the issue. As a temporary workaround, consider sanitizing the filename attribute in the `showFileNotExits()` function to prevent the execution of malicious JavaScript code. Implement a stronger password reset mechanism, such as not showing a password reset link to an already logged-in user, generating a password reset link when a reset is requested by a user and sending it by mail, and adding an expiration date to the token. Implement a strong Content Security Policy to mitigate other XSS sinks.

**Name of the Vulnerable Software and Affected Versions** YesWiki versions up to and including 4.4.5 **Description** The issue allows any authenticated user to arbitrarily remove content from the Wiki, resulting in partial loss of data and defacement/deterioration of the website. This is possible through the use of the file manager, which does not properly sanitize or verify the path provided by the user, allowing a malicious user to specify any arbitrary file on the filesystem for deletion. The vulnerability can be exploited by accessing the `filemanager` and using the `fmErase()` function, which does not restrict the deletion to specific directories or files. In a standard installation, this could allow a malicious user to delete important PHP files, such as `index.php` or core files of YesWiki, thereby completely cutting off access to the wiki. **Recommendations** For YesWiki versions up to and including 4.4.5, consider updating to version 4.5.0, which contains a patch for this issue. As a temporary workaround, restrict the possible paths of `fmErase()` to the `upload path` directory and limit its use to trashed files only. Additionally, ensure that any request to `fmErase()` or `fmDelete()` originates from the owner of the resource to which the attachment is linked.

**Name of the Vulnerable Software and Affected Versions** YesWiki versions prior to 4.4.5 **Description** The use of a weak cryptographic algorithm and a hard-coded salt to hash the password reset key allows it to be recovered and used to reset the password of any account. This issue is due to the application using a weak cryptographic algorithm, specifically `md5`, to hash the password reset key, and a hard-coded salt defined in the `includes/services/UserManager.php` file. The key is generated from the user's name, e-mail address, a random number between 0 and 10000, the current date of the request, and the salt. If an attacker knows the user's name and e-mail address, they can retrieve the key and use it to reset the account password with a bit of brute force on the random number. **Recommendations** For versions prior to 4.4.5, the safest solution is to update to version 4.4.5, which fixes this issue by addressing the weak cryptographic algorithm and hard-coded salt used for password reset key hashing. As a temporary workaround, consider restricting access to the password reset functionality until a patch is available.