This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Fuel Cms
A stored cross-site scripting (XSS) vulnerability exists in FUEL-CMS 1.5.1 that allows an authenticated user to upload a malicious .pdf file which acts as a stored XSS payload. If this stored XSS payload is triggered by an administrator it will trigger a XSS attack. (2022-05-03, CVE-2022-28599)
Daylight Studio Fuel CMS 1.5.1 is vulnerable to HTML Injection. (2022-04-11, CVE-2022-27156)
A Cross Site Scripting (XSS) vulnerability exists in FUEL-CMS 1.5.1 in the Assets page via an SVG file. (2022-02-24, CVE-2021-44607)
An issue was discovered in FUEL CMS V1.4.7. An attacker can use a XSS payload and bypass a filter via /fuelCM/fuel/pages/edit/1?lang=english. (2021-03-10, CVE-2020-23721)
FUEL CMS 1.4.11 has stored XSS in Blocks/Navigation/Site variables. This could lead to cookie stealing and other malicious actions. This vulnerability can be exploited with an authenticated account and also impact other visitors. (2021-01-05, CVE-2020-26046)
FUEL CMS 1.4.4 has XSS in the Create Blocks section of the Admin console. This could lead to cookie stealing and other malicious actions. This vulnerability can be exploited with an authenticated account but can also impact unauthenticated visitors. (2019-08-20, CVE-2019-15228)
XSS exists in FUEL CMS 1.4.3 via the Header or Body in the Layout Variables during new-page creation, as demonstrated by the pages/edit/1?lang=english URI. (2018-12-13, CVE-2018-20136)
XSS exists in FUEL CMS 1.4.3 via the Page title, Meta description, or Meta keywords during page data management, as demonstrated by the pages/edit/1?lang=english URI. (2018-12-13, CVE-2018-20137)
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>