View Issue Details

IDProjectCategoryView StatusLast Update
0017362mantisbtsecuritypublic2015-03-14 05:19
Reporteravlidienbrunn Assigned Todregad  
Status closedResolutionfixed 
Product Version1.2.17 
Fixed in Version1.2.18 
Summary0017362: Multiple vulnerabilities in MantisBT


I couldn't find any contact email and the IRC was kinda silent so I'm just gonna go ahead and write it here. Sorry for only making one issue, but honestly I'm too lazy and unfamiliar with how you guys set up issues for security issues so I'll let someone else do that.

Recently I have been auditing MantisBT as part of taking part of offensive security's bug bounty program (see If you're not aware, they are using MantisBT on

I have reported several vulnerabilities that affects MantisBT to them and I'm not sure which have been referred to you guys which is why I'm writing this report. I'm just going to list them one by one:

  1. Unrestricted redirect: The URL validator doesn't handle protocol relative URI's correctly, so any redirect only relying on this can be made into an unrestricted redirect. PoC:\/ will take you to

  2. Persistent XSS in comments: Add a comment with this: &javascript://%E2%80%A8alert(document.domain) and it will make a link which will execute JavaScript when clicked. The problem lies in, the function "string_insert_hrefs" doesn't validate the protocol, which is why one can make this link (with some quirks) and execute javascript.

  3. Persistent XSS in uploads: It's possible to upload Flash files and make open them inline by using an image extension. Since Flash files can execute JavaScript this becomes a persistent XSS.

  4. PHP Object Injection: In the function current_user_get_bug_filter (core\current_user_api.php line 212). The code loads a variable from $_GET['filter']/$_POST['filter'] and if it's not numeric, feeds it straight into unserialize() on line 223.

The current_user_get_bug_filter function is called in 10 places, easiest is just to access /view_filters_page.php.

A PoC initializing a class that's loaded could look like this: /view_filters_page.php?filter=O:16:"MantisPHPSession":2:{s:2:"id";s:1:"1";s:3:"key";s:3:"wee";}

  1. Reflected XSS in admin panel: PoC: [MantisBT]/admin/test_langs.php?dest_id=<script>alert(1)</script>

  2. DB Credentials leak: When [MantisBT]/admin/upgrade_unattended.php? is accessed, MantisBT will connect to with the current DB config credentials.

TagsNo tags attached.
Attached Files
domain.swf.jpg (283 bytes)   
domain.swf.jpg (283 bytes)   


related to 0019493 closeddregad CVE-2014-9701: XSS vulnerability in permalink_page.php 
parent of 0017297 closeddregad CVE-2014-9272: XSS in string_insert_hrefs allows script execution 
parent of 0017648 closeddregad CVE-2014-6316: URL redirection issue 
parent of 0017874 closeddregad CVE-2014-9271: Persistent XSS in file uploads/attachments 
parent of 0017875 closeddregad CVE-2014-9280: PHP Object Injection in filter API 
parent of 0017877 closeddregad CVE-2014-9279: Db Credentials leak via unattended upgrade script 
parent of 0017876 closeddregad CVE-2014-9281: Reflected XSS in admin panel / copy_field.php 
has duplicate 0017392 closedgrangeway PHP Object injection issue in MantisBT 
related to 0017698 closeddregad An Open Redirect Vulnerability discovered 




2014-05-21 15:12

reporter   ~0040611

Thanks for reporting the bug, we'll take it from here.



2014-05-21 18:16

reporter   ~0040613

And if you don't mind, I'll take on fixing this bunch (as some of these issues I'm already aware of and have some fixes in progress - hence the mail I sent internally on a week and a half ago about possible XSS issues (the patch I supplied for the non-issue was actually the start of part of a set)):

For example, a similar problem to 2 exists with /permalink_page.php?url=javascript%3Aalert%284222%29

There's also a similar issue in the content displayed in one of our manage config pages.

The first issue (somewhat amusingly) - I'm aware of an alternative exploit path of /login_cookie_test.php?return= and been working on a fix for that already.

3 is definitely a new and not something I've already got on my radar - I've wondered before about uploading php files etc, and about virus's in images etc, but never considered flash objects and javascript - Without testing tonight as it's late - I wonder if our use of finfo to work out a mime type in 1.3 helps avoid this, or makes it worse. I suspect neither as iirc without looking at code, it was used to set the mimetype stored in the database as opposed to checking.

For 4 - and yes - equally, I've been trying to use the MANTIS_collapse_settings cookie to do the same via the Token_API

In terms of number 5 - are you sure you meant test_langs.php. In 1.3-master, there's an issue within copy_field.php of doing something similar of:

admin/copy_field.php?source_id=1&dest_id="></a><script>alert()</script><b style="

I've just tried your test_langs example with both my 1.3 code, and what I think is my 1.2.17 instance and not finding an issue with that particular page - Am I missing something here, or have you used the wrong file path in the example.

For 6 - good catch

1) grangeway will look at patches for this bunch
2) avlidienbrunn/others: can someone confirm if you number 5 really does mean test_langs.php and tell me what i'm missing
3) I'll leave someone else to work out a write up on this mess later on ;)
4) I plan to also submit a patch to disable the autocomplete html attribute on the password field on the account_page.php and login_page.php for good practice - as I believe that's not set.



2014-05-21 18:46

developer   ~0040615

To facilitate tracking of the 6 individual issues reported by avlidienbrunn, I propose the following approach, expanding on grangeway's summary:

0) [NEW] create 1 issue for each distinct security problem, and assign them as child of this one

1) grangeway will look at patches for this bunch

Thanks. Please create one commit per patch if possible, and if not at least reference each issue in the commit messages, to facilitate the documentation for CVEs.

2) avlidienbrunn/others: can someone confirm if you number 5 really does mean test_langs.php and tell me what i'm missing

I can't reproduce the issue with test_langs.php. There is no dest_id param in this script - in fact it does not use any parameters at all. I can however confirm the issue with copy_field.php [1]

3) I'll leave someone else to work out a write up on this mess later on ;)

I can take care of requesting CVEs and preparing the security release, provided you give me the required raw information (see [2] for details)

4) I plan to also submit a patch to disable the autocomplete html attribute on the password field on the account_page.php and login_page.php for good practice - as I believe that's not set.

That's not really an urgent security issue requiring immediate fixing, and furthermore unless I'm mistaken the autocomplete attribute is HTML5 only and therefore can't be used in 1.2.x (document type = xhtml1), so I would suggest to create a separate issue with 1.3.x target for this.

[1] http://localhost/mantis/admin/copy_field.php?source_id=1&amp;dest_id=%3Cscript%3Ealert%281%29%3C/script%3E
[2] f



2014-05-21 18:48

developer   ~0040616

@grangeway, as a side note, care to have a second look at your comment "Removing the admin folder doesn't really increase security" (0017345:0040567) ? ;-)



2014-05-21 19:36

reporter   ~0040618

Damien - actually, unattended_upgrade.php is a file I've tended to remove and replace with the updated installer in 2.0, so this issue doesn't exist at that point.

And equally in this case, this is us being dumb - you can write dumb code anywhere within mantis if you try - I'd suggest not using a computer as the solution to that one ;)

Lets think about the purpose of upgrade_unattended.php (probably the most serious of the issues in the list)

The purpose is to upgrade an existing installation:

So step 1:

$result = @db_connect( config_get_global( 'dsn', false ), config_get_global( 'hostname' ),
config_get_global( 'db_username' ), config_get_global( 'db_password' ),
config_get_global( 'database_name' ) );

This is safe. If this fails we abort

Step 2:

We ask for query string input

That's just dumb ;)

After step 1, you already have a valid database connection to a valid database for the update, so why throw it away. The "blame" for that logic goes back to giallu/victor in 2007 and Mantis 1.1.0a3.

Personally (and clarifying my first statement about I've tended to gear towards trying to remove that file): We have an install.php - that should really have a silent mode for upgrades (for those that want it) as opposed to have 2 different installation processes.

In terms of supporting the argument regarding the amount of use upgrade_unattended.php receives:

The code for upgrade_unattended actually was broken (i.e. the script working as opposed to the security issue that always existed) on August 9th 2007 by thraxisp with . This means that it stopped working in the following release:


Victor added support to fix the script following the August 9th 2007 change on December 29th 2013

In short, the only versions of Mantis that have had valid logic for upgrade_unattended.php have been:

1.1.0rc3 - released 2007-11-23
1.1.0rc2 - release 2007-10-04
1.1.0rc1 - 2007-08-02
1.1.0a4 - 2007-08-01
1.1.0a3 - 2007-05-08

Evidently it's a well used feature :p I would make a list of the versions we've released since 1.1.0rc3 that haven't worked, but it's bedtime unfortunately ;)

side note - whilst I had thought that having a silent upgrade option was important, it does make me wonder the value of actually having said option giving the likihood of breaking it and not noticing ;)



2014-05-22 17:02

reporter   ~0040625

Assigning this to Myself. there'll be a patch for this at some point over weekend + during the following week.

P.S As a warning guys, I've got more time then usual next week - off work for the week, so I need a few things to keep me quiet :)




2014-05-22 17:13

reporter   ~0040626

Last edited: 2014-05-22 17:21

Hi! I do mean copy_field.php. Need anything else from me? I'd love to get credited on the CVE if possible too :)

Edit: I also uploaded a PoC SWF file to this issue for demonstration. If you open the link with inline token it'll execute alert(document.domain).




2014-05-22 17:58

reporter   ~0040627

That's fine IMO (re credit) - I'm not sure if it's a good thing that I've come across some of the security issues reported or not (arguably it's a bad thing as they should have been fixed - albeit, some of the things I mentioned I spotted a week before you)

In terms of the PoC SWF, shouldn't that work on this bug report? At least, I'm finding it not to work in IE11 on here.



2014-05-22 18:24

developer   ~0040628

Last edited: 2014-05-22 18:25

With regards being credited on the CVE, of course you'll be referenced as reporter. Please indicate precisely how you'd like your name to appear (i.e. nickname, full name, e-mail, web site, company...)



2014-08-26 10:14

reporter   ~0041126

Was a CVE ever assigned to this(these) issues? It's fine with "Mathias Karlsson" and a link to if it's not already made.



2014-08-26 18:47

developer   ~0041128

Reminder sent to: grangeway

Paul, where are those patches ?

@avlidienbrunn - I never requested a CVE, because once I do the issue de facto becomes public, and I don't want to disclose without having a fix available.



2014-09-22 05:32

developer   ~0041264

For point 1. Unrestricted redirect, CVE-2014-6316 was assigned (see 0017648)

@grangeway, it's been 4 months, where are the patches !!!!!



2014-09-22 05:45

reporter   ~0041266

@dregad gotcha



2014-09-22 13:28

reporter   ~0041269

@dregad - still waiting for victor to add SSH key so I can push private branch. Hopefully he'll get round to it soon.



2014-09-22 21:36

manager   ~0041291

@grangeway, the answer to your question can be found at:

Server access is not needed to address this. There is no plans to host git repositories on the server.



2014-10-06 15:23

reporter   ~0041434

Oh for god's sake, do we delay patching a security fix for 4 MONTHS because we're setting up a gitlab instance?

That's just stupid, sorry. And the kind of thing that makes for bad products and bad reputation amongst our users. I don't have the time to fix this myself, but I have the time to say how unbelievably obtuse this is.<EOM>



2014-10-06 17:57

reporter   ~0041436

Last edited: 2014-10-07 05:47

[EDIT] dregad - urldecoding grangeway's prose...

Rombert - no - I said originally I had a branch where it would help people to review if they could see history rather then a patch, and said i'd copy it to our server as soon as Victor added ssh key.

So moved on to next thing whilst waiting on victor, to respond.

In the past we've given all team members to the server - we all used to have access in the past until server changed, and have been asking since then (And getting told since then that it'll be added), so at the time I was expecting it to be a quick job.

Where atrol's suggested in a private note today about using my server and giving you guys access, that approach can be implemented by this weekend.



2014-10-07 04:42

reporter   ~0041441

Paul - sorry, I 'm not sure what you wrote there, it's painful to parse :-)

But the gist is - we're hiding behind process, and that's counterproductive. I for one don't want to get any private access as long as we can attach a git patchset to this bug!



2014-10-07 05:34

developer   ~0041443

Last edited: 2014-10-07 05:34

Paul, didn't read that garbled mess you just posted, but regardless your position is untenable and you know it.

Holding security patches hostage to get a server access that Victor repeatedly said he would not grant is just plain ridiculous, and don't even get me started about your mentioning that in communications with users [e.g. 0017725:0041380] !

For the issue at hand, if you fix MantisForge that's fine as I've been requesting that for months (actually, over a year I think) but it's really not necessary:

  • git format-patch will generate a series of .patch files (one per commit), thus preservign history of changes
  • the patches can easily be applied using git am.

So just generate the files, attach them to the issue(s) (as a zip file if needed) and let's be done with it.



2014-11-14 19:37

developer   ~0041842

Child issues now exist for each of the 6 points originally reported:

  1. 0017648
  2. 0017297
  3. 0017874
  4. 0017875
  5. 0017876
  6. 0017877


2014-11-17 02:44

developer   ~0041861

Closed by mistake



2015-03-14 05:19

developer   ~0049212

Following up on TWSpiders's report of an XSS issue in permalink_page.php (see 0019493), I'm linking it here for the record since it was initially reported by grangeway in note 0017362:0040613.

[...] mail I sent [...] about possible XSS issues [...]

For example, a similar problem to 2 exists with /permalink_page.php?url=javascript%3Aalert%284222%29