This article is a part of our Vulnerability Database (back to index)

Cross-site Scripting occurrences in Bludit

A vulnerability was found in Bludit 3.13.1. It has been declared as problematic. This vulnerability affects the endpoint /admin/new-content of the New Content module. The manipulation of the argument content with the input leads to cross site scripting. The attack can be initiated remotely but requires an authentication. The exploit has been disclosed to the public and may be used. (2022-05-05, CVE-2022-1590)

A Stored Cross Site Scripting (XSS) vulnerability exists in Bludit 3.13.1 via the About Plugin in login panel. (2022-01-06, CVE-2021-45745)

A Stored Cross Site Scripting (XSS) vulnerability exists in bludit 3.13.1 via the TAGS section in login panel. (2022-01-06, CVE-2021-45744)

Cross Site Scripting (XSS) vulnerability exists in bludit 3-13-1 via the username in admin/login. (2021-10-19, CVE-2021-35323)

Bludit 3.12.0 allows stored XSS via JavaScript code in an SVG document to bl-kernel/ajax/logo-upload.php. (2020-06-24, CVE-2020-15006)

showAlert() in the administration panel in Bludit 3.12.0 allows XSS. (2020-06-06, CVE-2020-13889)

** DISPUTED ** Bludit 3.10.0 allows Editor or Author roles to insert malicious JavaScript on the WYSIWYG editor. NOTE: the vendor's perspective is that this is "not a bug." (2020-02-07, CVE-2020-8812)

In Bludit v3.9.2, there is a persistent XSS vulnerability in the Categories -> Add New Category -> Name field. NOTE: this may overlap CVE-2017-16636. (2019-09-15, CVE-2019-16334)

Bludit 2.3.4 allows XSS via a user name. (2018-09-01, CVE-2018-16313)

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>

Scan Your Web App Now
Scan your application
for 14 days for free

No credit card is required. No commitment.

Sign Up Free