This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Marktext
A stored cross-site scripting vulnerability in marktext versions prior to v0.17.0 due to improper handling of the link (with javascript: scheme) inside the document may allow an attacker to execute an arbitrary script on the PC of the user using marktext. (2022-03-10, CVE-2022-21158)
Mark Text v0.16.3 was discovered to contain a DOM-based cross-site scripting (XSS) vulnerability which allows attackers to perform remote code execution (RCE) via injecting a crafted payload into /lib/contentState/pasteCtrl.js. (2022-03-05, CVE-2022-25069)
MarkText through 0.16.3 does not sanitize the input of a mermaid block before rendering. This could lead to Remote Code Execution via a .md file containing a mutation Cross-Site Scripting (XSS) payload. (2022-01-29, CVE-2022-24123)
Mark Text through 0.16.3 allows attackers arbitrary command execution. This could lead to Remote Code Execution (RCE) by opening .md files containing a mutation Cross Site Scripting (XSS) payload. (2021-04-05, CVE-2021-29996)
Mutation XSS exists in Mark Text through 0.16.2 that leads to Remote Code Execution. NOTE: this might be considered a duplicate of CVE-2020-26870; however, it can also be considered an issue in the design of the "source code mode" feature, which parses HTML even though HTML support is not one of the primary advertised roles of the product. (2020-10-16, CVE-2020-27176)
Why Cross-site Scripting can be dangerous
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>