#xss

### Impact Directus allows an authenticated attacker to save cross site scripting code to the database. This is possible because the application injects an attacker-controlled parameter that will be stored in the server and used by the client into an unsanitized DOM element. When chained with [CVE-2024-6534](https://github.com/directus/directus/security/advisories/GHSA-3fff-gqw3-vj86), it could result in account takeover. ### PoC To exploit this vulnerability, we need to do the following steps using a non-administrative, default role attacker account. 1. Upload the following JavaScript file. Using the upload functionality at `POST /files`. This PoC will show an alert message. ```js export TARGET_HOST="http://localhost:8055" export ATTACKER_EMAIL="malicious@malicious.com" export ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_se...

If a website has been set to the "dev" environment mode, a URL can be provided which includes an XSS payload which will be executed in the resulting error message.

An issue was discovered in phpMyAdmin 5.x before 5.2.2. An XSS vulnerability has been discovered for the check tables feature. A crafted table or database name could be used for XSS.

Stored Cross-Site Scripting (XSS) in the Categorization Option of My Subscriptions Functionality in Silverpeas Core 6.4.1 allows a remote attacker to execute arbitrary JavaScript code. This is achieved by injecting a malicious payload into the Name field of a subscription. The attack can lead to session hijacking, data theft, or unauthorized actions when an admin user views the affected subscription.

### Impact This can not be exploited in a fresh install of PrestaShop, only shops made vulnerable by third party modules are concerned. For example, if your shop has a third party module vulnerable to SQL injections, then ps_contactinfo might execute a stored XSS in FO. ### Patches The long term fix is to have all your modules maintained and updated. The fix on ps_contactinfo will keep formatted addresses from displaying an xss stored in the database. ### Workarounds none ### References none

### Impact Authenticated users are able to exploit an XSS vulnerability when viewing previewed content. ### Patches Will be patched in 10.8.8, 13.5.3, 14.3.2 and 15.1.2. ### Workarounds None available.

### Summary Despite normal text rendering as LaTeX expressions, preventing XSS, the library also provides users with commands which may modify HTML, such as the `\htmlData` command, and the lack of escaping leads to XSS. ### Details Overall in the code, other than in the `test` folder, no functions escaping HTML can be seen. ### PoC 1. Go to https://cortexjs.io/mathlive/demo/ 2. Paste either `\htmlData{><img/onerror=alert(1)"src=}{}` or `\htmlData{x=" ><img/onerror=alert(1) src>}{}` in the LaTeX textarea. ### Impact MathLive users who render untrusted mathematical expressions could encounter malicious input using \htmlData that runs arbitrary JavaScript, or generate invalid HTML.

### Summary The researcher discovered zero-day vulnerability Cross-Site Scripting (XSS) vulnerability in the code which translates the XLSX file into a HTML representation and displays it in the response. ### Details When generating the HTML from an xlsx file containing multiple sheets, a navigation menu is created. This menu includes the sheet names, which are not sanitized. As a result, an attacker can exploit this vulnerability to execute JavaScript code. ```php // Construct HTML $html = ''; // Only if there are more than 1 sheets if (count($sheets) > 1) { // Loop all sheets $sheetId = 0; $html .= '<ul class="navigation">' . PHP_EOL; foreach ($sheets as $sheet) { $html .= ' <li class="sheet' . $sheetId . '"><a href="#sheet' . $sheetId . '">' . $sheet->getTitle() . '</a></li>' . PHP_EOL; ++$sheetId; } $html .= '</ul>' . PHP_EOL; } ``` ...

# Authenticated Stored XSS in YesWiki <= 4.4.5 ### Summary It is possible for an authenticated user with rights to edit/create a page or comment to trigger a stored XSS which will be reflected on any page where the resource is loaded. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the content edition feature and more specifically of the `{{attach}}` component allowing users to attach files/medias to a page. When a file is attached using the `{{attach}}` component, if the resource contained in the `file` attribute doesn't exist, then the server will generate a file upload button containing the filename. This part of the code is managed in `tools/attach/libs/attach.lib.php` and the faulty function is **[showFileNotExits()](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/att...

# Unauthenticated DOM Based XSS in YesWiki <= 4.4.5 ### Summary It is possible for any end-user to craft a DOM based XSS on all of YesWiki's pages which will be triggered when a user clicks on a malicious link. This Proof of Concept has been performed using the followings: - YesWiki v4.4.5 (`doryphore-dev` branch, latest) - Docker environnment (`docker/docker-compose.yml`) - Docker v27.5.0 - Default installation ### Details The vulnerability makes use of the search by tag feature. When a tag doesn't exist, the tag is reflected on the page and isn't properly sanitized on the server side which allows a malicious user to generate a link that will trigger an XSS on the client's side when clicked. This part of the code is managed by `tools/tags/handlers/page/listpages.php`, and **[this piece of code](https://github.com/YesWiki/yeswiki/blob/doryphore-dev/tools/tags/handlers/page/listpages.php#L84)** is responsible for the vulnerability: ```php $output .= '<div class="alert alert-info">...