Source
ghsa
### Summary An arbitrary file write can be used to write a file with a PHP extension, which then can be browsed to in order to execute arbitrary code on the server. All testing was performed on a local docker setup running the latest version of the application. ### PoC Proof of Concept Navigate to `http://localhost:8085/?LookWiki` which allows you to click `Create a new Graphical configuration` where you specify some parameters and then click `Save`.  After clicking save, this request is made (most headers removed for clarity): ``` POST /?api/templates/custom-presets/test.css HTTP/1.1 Host: localhost:8085 primary-color=%230c5d6a&secondary-color-1=%23d8604c&secondary-color-2=%23d78958&neutral-color=%234e5056&neutral-soft-color=%2357575c&neutral-light-color=%23f2f2f2&main-text-fontsize=17px&main-text-fontfamily=%22Nunito%22%2C+sans-serif&main-title-fontfamily='Nunito'%2C+sans-serif ``` ...
### Summary The request to commence a site backup can be performed without authentication. Then these backups can also be downloaded without authentication. The archives are created with a predictable filename, so a malicious user could create an archive and then download the archive without being authenticated. ### Details Create an installation using the instructions found in the docker folder of the repository, setup the site, and then send the request to create an archive, which you do not need to be authenticated for: ``` POST /?api/archives HTTP/1.1 Host: localhost:8085 action=startArchive¶ms%5Bsavefiles%5D=true¶ms%5Bsavedatabase%5D=true&callAsync=true ``` Then to retrieve it, make a simple `GET` request like to the correct URL: ``` http://localhost:8085/?api/archives/2025-04-12T14-34-01_archive.zip ``` A malicious attacker could simply fuzz this filename. ### PoC Here is a python script to fuzz this: ``` #!/usr/bin/env python3 import requests import argpars...
### Summary Reflected XSS has been detected in the file upload form. Vulnerability can be exploited without authentication This Proof of Concept has been performed using the followings: - YesWiki v4.5.3 (doryphore-dev branch) - Docker environnment (docker/docker-compose.yml) ### Vulnerable code The vulnerability is located in the [file](https://github.com/YesWiki/yeswiki/blob/6894234bbde6ab168bf4253f9a581bd24bf53766/tools/attach/libs/attach.lib.php#L724-L735) ``` public function showUploadForm() { $this->file = $_GET['file']; echo '<h3>' . _t('ATTACH_UPLOAD_FORM_FOR_FILE') . ' ' . $this->file . "</h3>\n"; echo '<form enctype="multipart/form-data" name="frmUpload" method="POST" action="' . $this->wiki->href('upload', $this->wiki->GetPageTag()) . "\">\n" . ' <input type="hidden" name="wiki" value="' . $this->wiki->GetPageTag() . "/upload\" />\n" . ' <input type="hidden" name="MAX_FILE_SIZE" value="' . ...
### Summary **Vulnerable Version:** Yeswiki < v4.5.4 **Vulnerable Endpoint:** `/?PagePrincipale%2Fdeletepage` **Vulnerable Parameter:** `incomingurl` **Payload:** `"><script>alert(1)</script>` ### Details Reflected Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. ### PoC **NOTE:** This vulnerability requires admin access. 1. Visit the endpoint as mentioned below and see that an alert box pops up: **URL with Payload:** `https://yeswiki.net/?PagePrincipale%2Fdeletepage&incomingurl="><script>alert(1)</script>` ### Impact An attacker can use a reflecte...
### Summary **Vulnerable Version:** Yeswiki < v4.5.4 **Category:** Injection **CWE: 79:** Improper Neutralization of Input During Web Page Generation (CWE-79) **CVSS:** 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) **Vulnerable Endpoint:** `/?BazaR` **Vulnerable Parameter:** `idformulaire` **Payload:** `<script>alert(1)</script>` ### Details Reflected Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. ### PoC 1. Visit the endpoint as mentioned below and see that an alert box pops up: **URL with Payload:** `https://yeswiki.net/?BazaR&vue=formulaire&ac...
### Summary **Vulnerable Version:** Yeswiki < v4.5.4 **Category:** Injection **CWE: 79:** Improper Neutralization of Input During Web Page Generation (CWE-79) **CVSS:** 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) **Vulnerable Endpoint:** `/?BazaR/bazariframe` **Vulnerable Parameter:** `template` **Payload:** `<script>alert(1)</script>` ### Details Reflected Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. ### PoC 1. Visit the endpoint as mentioned below and see that an alert box pops up: **URL with Payload:** `https://yeswiki.net/?BazaR/bazar...
### Impact When editing a page, XWiki warns since version 15.9 when there is content on the page like a script macro that would gain more rights due to the editing. This analysis doesn't consider certain kinds of properties, allowing a user to put malicious scripts in there that will be executed after a user with script, admin, or programming rights edited the page. Such a malicious script could impact the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, as a user without script right, create a class with a `TextArea` property, create page with an object of that class and a Velocity macro in its content. Then, as an admin, try editing that page. Normally, there should be a warning but in vulnerable versions of XWiki, there is no warning. ### Patches This vulnerability has been patched in XWiki 15.10.8 and 16.2.0. ### Workarounds We're not aware of any workarounds apart from not editing pages that might have been edited by untrusted users as ...
### Impact When a user with programming right edits a document in XWiki that was last edited by a user without programming right and contains an `XWiki.ComponentClass`, there is no warning that this will grant programming right to this object. An attacker who created such a malicious object could use this to gain programming right on the wiki. For this, the attacker needs to have edit right on at least one page to place this object and then get an admin user to edit that document. To reproduce the problem, as a user without programming right, add an object of type `XWiki.ComponentClass` to any page and then edit the page as a user with programming right. There should be warning displayed, if not, the XWiki installation is vulnerable. While such a warning didn't exist in any version of XWiki, only in XWiki 15.9 RC1 these kinds of warnings have been introduced which is why this is considered the first version that has this vulnerability. Before that, the advice was to be careful when ...
### Impact The script API of the LESS compiler in XWiki is incorrectly checking for rights when calling the cache cleaning API, making it possible to clean the cache without having programming right. The only impact of this is a slowdown in XWiki execution as the caches are re-filled. As this vulnerability requires script right to exploit, and script right already allows unlimited execution of scripts, the additional impact due to this vulnerability is low. ### Patches This has been patched in XWiki 15.10.12, 16.4.3 and 16.8.0 RC1. ### Workarounds We're not aware of any workaround except for being careful whom to give script right, which is a general recommendation.
### Impact The Solr script service that is accessible in XWiki's scripting API normally requires programming right to be called. Due to using the wrong API for checking rights, it doesn't take the fact into account that programming rights might have been dropped by calling `$xcontext.dropPermissions()`. If some code relies on this for the safety of executing Velocity code with the wrong author context, this could allow a user with script right to either cause a high load by indexing documents or to temporarily remove documents from the search index. We're not aware that this is exploitable in XWiki itself. To reproduce, a user with programming right can add the following XWiki syntax to a page: ``` {{velocity}} $xcontext.dropPermissions() $services.solr.index('document:xwiki:Main.WebHome') {{/velocity}} ``` This should trigger an error in XWiki's log, otherwise the installation is vulnerable. ### Patches This has been patched in XWiki 15.10.13, 16.8.0RC1, and 16.4.4. ### Workaroun...