Stored XSS in 'Table name' field via Database information function in yetiforcecompany/yetiforcecrm


Reported on

Aug 16th 2022


When the administrator uses the Database information function, malicious code will be accidentally called and executed through two cases:

  1. (1) An internal attacker (local) with access right to the database could insert malicious content into the table name field by creating a table in the database.
  2. (2) The second possible case is when the system administrator performs a malicious import of the database from an unknown source with the table name field injected by malicious content.

Proof of Concept


CREATE TABLE `yetiforce`.`<script>alert('stored_xss')</script>` ( `id` INT NOT NULL ) ENGINE = InnoDB CHARSET=armscii8 COLLATE armscii8_general_nopad_ci;

Reprodution steps

  • Step 1: The internal attacker create a new table with the payload above.

PoC - Step 1

  • Step 2: Access Database information function in Admin Dashboard > Logs > Server configuration

PoC - Step 2

  • Step 3: The XSS should fire immediately when detailed information about the database is loaded.

PoC - Step 3.1

PoC - Step 3.2


This vulnerability allows attackers to hijack the user's current session, steal relevant information, deface website or direct users to malicious websites,...

We are processing your report and will contact the yetiforcecompany/yetiforcecrm team within 24 hours. a year ago
A GitHub Issue asking the maintainers to create a exists a year ago
We have contacted a member of the yetiforcecompany/yetiforcecrm team and are waiting to hear back a year ago
Mariusz Krzaczkowski validated this vulnerability a year ago
0xb4c has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Mariusz Krzaczkowski marked this as fixed in 6.4.0 with commit a9ad9e a year ago
The fix bounty has been dropped
This vulnerability will not receive a CVE
to join this conversation