Seeddms Cross-site Scripting

SeedDMS versions 6.0.18 and 5.1.25 and below are vulnerable to stored XSS. An attacker with admin privileges can inject the payload inside the "Role management" menu and then trigger the payload by loading the "Users management" menu (2022-06-06, CVE-2022-28479)

The "Add category" functionality inside the "Global Keywords" menu in "SeedDMS" version 6.0.18 and 5.1.25, is prone to stored XSS which allows an attacker to inject malicious javascript code. (2022-06-06, CVE-2022-28051)

SeedDMS Content Management System v6.0.7 contains a persistent cross-site scripting (XSS) vulnerability in the component AddEvent.php via the name and comment parameters. (2021-10-22, CVE-2020-23048)

Cross-site scripting (XSS) exists in SeedDMS 6.0.13 via the folderid parameter to views/bootstrap/class.DropFolderChooser.php. (2020-12-07, CVE-2020-28727)

A stored XSS vulnerability was found in SeedDMS 5.1.11 due to poorly escaping the search result in the autocomplete search form placed in the header of out/out.Viewfolder.php. (2019-06-28, CVE-2019-12932)

out/out.UsrMgr.php in SeedDMS before 5.1.11 allows Stored Cross-Site Scripting (XSS) via the name field. (2019-06-20, CVE-2019-12745)

out/out.GroupMgr.php in SeedDMS 5.1.11 has Stored XSS by making a new group with a JavaScript payload as the "GROUP" Name. (2019-06-17, CVE-2019-12801)

Cross-Site Scripting (XSS) vulnerability in every page that includes the "action" URL parameter in SeedDMS (formerly LetoDMS and MyDMS) before 5.1.8 allows remote attackers to inject arbitrary web script or HTML via the action parameter. (2018-07-31, CVE-2018-12943)

Persistent Cross-Site Scripting (XSS) vulnerability in the "Categories" feature in SeedDMS (formerly LetoDMS and MyDMS) before 5.1.8 allows remote attackers to inject arbitrary web script or HTML via the name field. (2018-07-31, CVE-2018-12944)

Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.

The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:

https://server.com/confirmation?message=Transaction+Complete

what results in:

<span>Confirmation: Transaction Complete</span>

In that case the message can be modified to become a valid Javascript code, e.g.:

https://server.com/confirmation?message=<script>dangerous javascript code here</script>

and it will be executed locally by the user's browser with full access to the user's personal application/browser data:

<span>Confirmation: <script>dangerous javascript code here</script></span>