Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Forum/Board/Portal)  >   MercuryBoard Vendors:
MercuryBoard 'func/post.php' Input Validation Error in 'qu' Parameter Lets Remote Users Inject SQL Commands
SecurityTracker Alert ID:  1013137
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Updated:  Feb 17 2005
Original Entry Date:  Feb 9 2005
Impact:   Disclosure of system information, Disclosure of user information

Version(s): 1.1.1 and prior versions
Description:   An input validation vulnerability was reported in MercuryBoard. A remote user can inject SQL commands.

The 'func/post.php' script does not properly validate user-supplied input in the 'qu' parameter. A remote user can supply a specially crafted value to execute SQL commands on the underlying database.

A demonstration exploit URL to retrieve the administrator's password is provided:


In the demonstration exploit URL, the 't' parameter must refer to a valid topic number that the remote user can permission to reply to and the 'qu' parameter must refer to an invalid topic number.

Zeelock reported this variant of a vulnerability originally reported by Codebug Security.

Impact:   A remote user can execute arbitrary SQL commands on the underlying database.
Solution:   The vendor has issued a fixed version (1.1.2), available at:

Vendor URL: (Links to External Site)
Cause:   Input validation error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   None.

 Source Message Contents

Subject:  Mercuryboard =?iso-8859-1?Q?<=3D?= 1.1.1 Working Sql Injection

This is a MIME-formatted message.  If you see this text it means that your
mail software cannot handle MIME-formatted messages.

Content-Type: text/plain; format=flowed; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I made this just because the provided proof of concept by Andrea Trivero 
didn't work. 


Content-Disposition: attachment; filename=zk-mercuryboard.txt
Content-Type: text/plain; charset="iso-8859-1"; name=zk-mercuryboard.txt
Content-Transfer-Encoding: 7bit

{                           [   Zeelock-2005   ]                               }
{                                                                              }
{                          M E C U R Y  B O A R D                              }
{                                                                              }
{             [   Critical SQL Injection - Working Exploit  ]                  }
{                                                                              }
{                                                                              }

Date: 7th February 2005
Version Vulnerable: <= 1.1.1
Version Fixed: 1.1.2

"Validate anything can be passed. Security lays in the inputs. " - zk

MercuryBoard is a powerful message board system dedicated to raw speed with a 
mixture of features, ease of use, and ease of customization coupled with 
expandability, and diverse language services. Now just over two years in the 
making, version 1.0.0 is an immensely stable, thoroughly tested, and well
written piece of internet software ready for any webserver, running on PHP 
versions as low as 4.0.0 and MySQL versions as low as 3.22.

For More information:


Andrea Trivero of Codebug Security ( found a lot of security 
flaws inside this code: many XSS and some Sql injection.
Anyway he did not provide a real working exploit.

Looking at the following piece of code in func/post.php we can see that when the
"qu" variable is passed along with the "reply" switch we can inject anything
inside the "t" parameter passed via GET from the browser because it is not 
sanitized at all.

--------[ Mercury 1.1.1 original code ]-------------- 

if (($s == 'reply') && isset($this->get['qu'])) { 

$query = $this->db->fetch("SELECT p.post_text, m.user_name FROM { 

$this->pre}posts p, {$this->pre}users m WHERE p.post_id={ 

$this->get['qu']} AND p.post_author=m.user_id"); 

--------[/Mercury 1.1.1 original code ]--------------

Now we can try to inject something:

The only thing we have to keep in mind is that "t" parameter should refer to a 
"opic we have the permission to reply and the "qu" parameter should refer
to a non existing topic.

We get no errors so we can make something more.

Proof of concept

The nice thing is that you should see the Admin Username and the Admin Pwd Hash
inside the reply form between the [quote] tags.

Note: During the installation you may have chosen a different prefix for the 
tables. You need to modify the query in the right way to retrieve the 
information from the database.



Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC