This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Wuzhi Cms
A reflected Cross Site Scripting (XSS) in wuzhicms v4.1.0 allows remote attackers to execute arbitrary web script or HTML via the imgurl parameter. (2022-06-28, CVE-2020-19897)
A cross-site scripting (XSS) vulnerability in the system bulletin component of WUZHI CMS v4.1.0 allows attackers to steal the admin's cookie. (2021-12-21, CVE-2020-19770)
WUZHI CMS 4.1.0 has stored XSS via the "Extension module" "SMS in station" field under the index.php?m=core URI. (2019-03-07, CVE-2018-17426)
WUZHI CMS 4.1.0 has stored XSS via the "Membership Center" "I want to ask" "detailed description" field under the index.php?m=member URI. (2019-03-07, CVE-2018-17425)
XSS exists in WUZHI CMS 4.1.0 via index.php?m=attachment&f=imagecut&v=init&imgurl=[XSS] to coreframe/app/attachment/imagecut.php. (2019-02-25, CVE-2019-9107)
XSS exists in WUZHI CMS 4.1.0 via index.php?m=content&f=postinfo&v=listing&set_iframe=[XSS] to coreframe/app/content/postinfo.php. (2019-02-25, CVE-2019-9110)
XSS exists in WUZHI CMS 4.1.0 via index.php?m=message&f=message&v=add&username=[XSS] to coreframe/app/message/message.php. (2019-02-25, CVE-2019-9109)
An issue was discovered in WUZHI CMS 4.1.0. There is stored XSS in index.php?m=core&f=index via a seventh input field. (2018-11-05, CVE-2018-18939)
An issue was discovered in WUZHI CMS 4.1.0. There is stored XSS in index.php?m=core&f=index via an ontoggle attribute to details/open/ within a second input field. (2018-11-05, CVE-2018-18938)
XSS exists in WUZHI CMS 2.0 via the index.php v or f parameter. (2018-10-01, CVE-2018-17832)
WUZHI CMS 4.1.0 has XSS via the index.php?m=core&f=set&v=basic form[statcode] parameter. (2018-09-02, CVE-2018-16350)
WUZHI CMS 4.1.0 has XSS via the index.php?m=link&f=index&v=add form[remark] parameter. (2018-09-02, CVE-2018-16349)
An XSS vulnerability was discovered in WUZHI CMS 4.1.0. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the form[content] parameter to the index.php?m=feedback&f=index&v=contact URI. (2018-07-23, CVE-2018-14513)
An XSS vulnerability was discovered in WUZHI CMS 4.1.0. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the form[nickname] parameter to the index.php?m=core&f=set&v=sendmail URI. When the administrator accesses the "system settings - mail server" screen, the XSS payload is triggered. (2018-07-23, CVE-2018-14512)
An issue was discovered in WUZHI CMS 4.1.0 There is a Stored XSS Vulnerability in "Account Settings -> Member Centre -> Chinese information -> Ordinary member" via a QQ number, as demonstrated by a form[qq_10]= substring. (2018-05-29, CVE-2018-11549)
An issue was discovered in WUZHI CMS 4.1.0. There is XSS via the email parameter to the index.php?m=member&v=register URI. (2018-04-26, CVE-2018-10391)
An issue was discovered in WUZHI CMS 4.1.0. The "Extension Module -> System Announcement" feature has Stored XSS via an announcement. (2018-04-25, CVE-2018-10368)
An issue was discovered in WUZHI CMS 4.1.0. The content-management feature has Stored XSS via the title or content section. (2018-04-25, CVE-2018-10367)
A vulnerability was discovered in WUZHI CMS 4.1.0. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the tag[pinyin] parameter to the /index.php?m=tags&f=index&v=add URI. (2018-04-24, CVE-2018-10311)
WUZHI CMS 4.1.0 allows persistent XSS via the form%5Bqq_10%5D parameter to the /index.php?m=member&f=index&v=profile&set_iframe=1 URI. (2018-04-24, CVE-2018-10313)
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>