Cross-site Scripting (XSS) - Reflected in icecoder/icecoder


Reported on

Jan 14th 2022


Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into websites. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. is vulnerable to XSS as shown below:

Proof of concept

Vuln variable: $_POST['username']

        if ($ICEcoder["multiUser"]) {
            $_SESSION['username'] = $_POST['username'];


Login as an admin and enable multiuser and registration. Now register a new user with the following username:

admon<img src="x" onerror=alert`XSS`>

Set any password , for example:


Clic login observe the XSS....


Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.


We are processing your report and will contact the icecoder team within 24 hours. 2 years ago
We created a GitHub Issue asking the maintainers to create a 2 years ago
We have opened a pull request with a for icecoder to merge. 2 years ago
We have contacted a member of the icecoder team and are waiting to hear back 2 years ago
icecoder/icecoder maintainer validated this vulnerability 2 years ago
hitisec has been awarded the disclosure bounty
The fix bounty is now up for grabs
icecoder/icecoder maintainer marked this as fixed in 8.1 with commit 51cf24 2 years ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
icecoder/icecoder maintainer
2 years ago


Many thanks for the excellent report here, it allowed me to find & resolve the issue quickly.

I can confirm the input field "username" under multi-user mode indeed had an rXSS vuln (reflection within the editor.php file - within data seen after login).

While every security issue should be looked into and resolved, thankfully it's only exploitable if a user were to set the editor to multi-user mode and leave open so anyone could register. (In that case someone could register under a standard name and create new files using ICEcoder, for example - xss.js, rce.php, sqli.sql etc etc. So thankfully not exploitable unless someone had really bad "open to all" security practices in the first place).

Even so... it's technically a vulnerable point, needed patching and has been patched quickly. As ICEcoder follows the practice of "clean on output, not input" - the reflection on editor.php L153 is where I've fixed things, rather than input point settings.php L238.

Thanks again - it's fantastic researchers like yourself that make the web more secure. Kudos!

2 years ago



to join this conversation