hitoshura25/cvefixes huggingface dataset:
CVE-2018-9840 (Unknown, published 2018-04-10T05:29Z)
Description: value: The Open Whisper Signal app before 2.23.2 for iOS allows physically proximate attackers to bypass the screen locker feature via certain rapid sequences of actions that include app opening, clicking on cancel, and using the home button.
Severity: MEDIUM (CVSS v3 base score: 6.8)
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/signalapp/Signal-iOS
Files changed:
Commit message: Merge remote-tracking branch 'origin/charlesmchen/screenLockRework_' into release/2.23.2


Vulnerable code:

Fixed code:
CVE-2012-1118 (PHP, published 2012-06-29T19:55Z)
Description: value: The access_has_bug_level function in core/access_api.php in MantisBT before 1.2.9 does not properly restrict access when the private_bug_view_threshold is set to an array, which allows remote attackers to bypass intended restrictions and perform certain operations on private bug reports.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
core/access_api.php
Commit message: Fix bug in access_has_bug_level() for private issues

When private_bug_threshold is defined as an array instead of a single
access level, e.g. array(0=>40, 1=>70, 2=>90) to prevent developers
from seeing private bugs while granting that privilege to updaters,
access_has_bug_level() incorrectly returned true.

The consequence is that unwanted access to Private bugs was granted to
users who are allowed to view them, e.g. allowing them to delete or
perform other restricted actions.

Fixes #10124


Vulnerable code:
	# If the bug is private and the user is not the reporter, then the
	#  the user must also have higher access than private_bug_threshold
		$p_access_level = max( $p_access_level, config_get( 'private_bug_threshold' ) );

Fixed code:
	# If the bug is private and the user is not the reporter, then
	# they must also have higher access than private_bug_threshold
		$t_access_level = access_get_project_level( $t_project_id, $p_user_id );
		return access_compare_level( $t_access_level, config_get( 'private_bug_threshold' ) )
		    && access_compare_level( $t_access_level, $p_access_level );
CVE-2012-1119 (PHP, published 2012-06-29T19:55Z)
Description: value: MantisBT before 1.2.9 does not audit when users copy or clone a bug report, which makes it easier for remote attackers to copy bug reports without detection.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
bug_actiongroup.php
core/bug_api.php
core/history_api.php
Commit message: Fix #13816: Update history when copying issues

Until now, copying bugs using the "View Issues" page creates wrong/
incomplete history (entries for notes reflect the id's of the original
issue's notes) and also does not record any trace that the new issue is
in fact clone of another, which can be a source of confusion.

This commit prevents the duplication of the original bug's history,
generating instead a single history entry similar to what happens when
cloning a bug with the Clone button in view.php page.

The display of history entries for cloned bugs has been slightly
modified, the bug id is now printed under the 'Field' column instead of
the 'Change' column, like entries for adding notes (as cloning s not a
change).


Vulnerable code:
			bug_copy( $t_bug_id, $f_project_id, true, true, true, true, true, true );
					$t_note = lang_get( 'bug_cloned_to' );
					$t_change = bug_format_id( $p_new_value );
					$t_note = lang_get( 'bug_created_from' );
					$t_change = bug_format_id( $p_new_value );

Fixed code:
			# Copy everything except history
			bug_copy( $t_bug_id, $f_project_id, true, true, false, true, true, true );
 * @param bool p_copy_history
 * @param bool p_copy_attachments
 * @param bool p_copy_bugnotes
 * @param bool p_copy_monitoring_users
	# Create history entries to reflect the copy operation
	history_log_event_special( $t_new_bug_id, BUG_CREATED_FROM, '', $t_bug_id );
	history_log_event_special( $t_bug_id, BUG_CLONED_TO, '', $t_new_bug_id );

					$t_note = lang_get( 'bug_cloned_to' ) . ': ' . bug_format_id( $p_new_value );
					$t_note = lang_get( 'bug_created_from' ) . ': ' . bug_format_id( $p_new_value );
CVE-2012-1119 (PHP, published 2012-06-29T19:55Z)
Description: value: MantisBT before 1.2.9 does not audit when users copy or clone a bug report, which makes it easier for remote attackers to copy bug reports without detection.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
core/bug_api.php
Commit message: Add "New Issue" entry to history when copying bugs

When bug_copy() is called with p_copy_history=false, a 'NEW_BUG' history
entry is added to ensure consistency of behavior with Clone button.

Fixes #13816


Vulnerable code:

Fixed code:
		# @todo problem with this code: the generated history trail is incorrect because the note IDs are those of the original bug, not the copied ones
		# @todo actually, does it even make sense to copy the history ?
	} else {
		# Create a "New Issue" history entry
		history_log_event_special( $t_new_bug_id, NEW_BUG );
CVE-2012-1121 (PHP, published 2012-06-29T19:55Z)
Description: value: MantisBT before 1.2.9 does not properly check permissions, which allows remote authenticated users with manager privileges to (1) modify or (2) delete global categories.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
manage_proj_cat_delete.php
manage_proj_cat_edit_page.php
manage_proj_page.php
Commit message: User must have global access to update global categories

The user's global access level must be >= $g_manage_site_threshold to
be allowed to add, edit or delete global categories.

Prior to this, once a user had been defined as Manager on at least one
project, they could freely update global categories.

Also prevents such updates through URL manipulation.

Fixes #13561


Vulnerable code:
access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );

access_ensure_project_level( config_get( 'manage_project_threshold' ), $f_project_id );

	foreach ( $t_categories as $t_category ) {

Fixed code:
access_ensure_project_level( config_get( 'manage_project_threshold' ), $t_project_id );

access_ensure_project_level( config_get( 'manage_project_threshold' ), $t_project_id );

		$t_can_update_global_cat = access_has_global_level( config_get( 'manage_site_threshold' ) );

			<?php if( $t_can_update_global_cat ) { ?>
			<?php } ?>
	foreach( $t_categories as $t_category ) {
			<?php if( $t_can_update_global_cat ) { ?>
			<?php } ?>
<?php if( $t_can_update_global_cat ) { ?>
<?php } ?>
CVE-2012-1122 (PHP, published 2012-06-29T19:55Z)
Description: value: bug_actiongroup.php in MantisBT before 1.2.9 does not properly check the report_bug_threshold permission of the receiving project when moving a bug report, which allows remote authenticated users with the report_bug_threshold and move_bug_threshold privileges for a project to bypass intended access restrictions and move bug reports to a different project.
Severity: LOW (CVSS v3 base score: )
Weakness: CWE-264 \u2014 Permissions, Privileges, and Access Controls
Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
bug_actiongroup.php
Commit message: Fix Move bugs from projects with access < report_bug_threshold

The access check in bug_actiongroup.php was not correct. It should
verify the user's report_bug_threshold in the target project, not the
current project.

Fixes #13748


Vulnerable code:
		if ( access_has_bug_level( config_get( 'move_bug_threshold' ), $t_bug_id ) &&
		     access_has_project_level( config_get( 'report_bug_threshold' ), $f_project_id ) ) {

Fixed code:
		if( access_has_bug_level( config_get( 'move_bug_threshold' ), $t_bug_id ) &&
		    access_has_project_level( config_get( 'report_bug_threshold', null, null, $f_project_id ), $f_project_id ) ) {
CVE-2012-1123 (PHP, published 2012-06-29T19:55Z)
Description: value: The mci_check_login function in api/soap/mc_api.php in the SOAP API in MantisBT before 1.2.9 allows remote attackers to bypass authentication via a null password.
Severity: HIGH (CVSS v3 base score: )
Weakness: CWE-287 \u2014 Improper Authentication
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
api/soap/mc_api.php
Commit message: Fix 0013901: SOAP API allows invoking methods without proper authentication

Note: only applied to 1.2.x not 'next', as the code is changing anyway


Vulnerable code:

Fixed code:
	} else {
		if( is_blank( $p_password ) ) {
			# require password for authenticated access
			return false;
		}
CVE-2013-4460 (PHP, published 2014-01-10T15:55Z)
Description: value: Cross-site scripting (XSS) vulnerability in account_sponsor_page.php in MantisBT 1.0.0 through 1.2.15 allows remote authenticated users to inject arbitrary web script or HTML via a project name.
Severity: LOW (CVSS v3 base score: )
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
account_sponsor_page.php
Commit message: Fix #16513: XSS in account_sponsor_page.php project names

account_sponsor_page.php.php does not correctly sanitise project
names. It is thus possible for a malicious user with project
manager access permissions (or higher) to let users execute
malicious JavaScript when visiting account_sponsor_page.php.


Vulnerable code:
		echo '<td>' . project_get_field( $t_bug->project_id, 'name' ) . '&#160;</td>';
		echo '<td>' . project_get_field( $t_bug->project_id, 'name' ) . '&#160;</td>';

Fixed code:
		echo '<td>' . string_display_line( project_get_field( $t_bug->project_id, 'name' ) ) . '&#160;</td>';
		echo '<td>' . string_display_line( project_get_field( $t_bug->project_id, 'name' ) ) . '&#160;</td>';
CVE-2014-8553 (PHP, published 2014-12-17T19:59Z)
Description: value: The mci_account_get_array_by_id function in api/soap/mc_account_api.php in MantisBT before 1.2.18 allows remote attackers to obtain sensitive information via a (1) mc_project_get_users, (2) mc_issue_get, (3) mc_filter_get_issues, or (4) mc_project_get_issues SOAP request.
Severity: MEDIUM (CVSS v3 base score: )
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
api/soap/mc_account_api.php
Commit message: SOAP API: apply access control to mci_account_get_array_by_id

The access controls are the same as the ones applied by
view_user_page.php, with the single addition of making the info
available if the user requests their own information.

This preserves the behaviour of the mc_login method call.

Fixes #17243 (leak of user personal information)

Signed-off-by: Damien Regad <dregad@mantisbt.org>


Vulnerable code:
		$t_dummy = user_get_field( $p_user_id, 'realname' );
		if( !empty( $t_dummy ) ) {
			$t_result['real_name'] = $t_dummy;
		$t_dummy = user_get_field( $p_user_id, 'email' );
		if( !empty( $t_dummy ) ) {
			$t_result['email'] = $t_dummy;

Fixed code:

		$t_current_user_id = auth_get_current_user_id();
		$t_access_level = user_get_field ( $t_current_user_id, 'access_level' );
		$t_can_manage = access_has_global_level( config_get( 'manage_user_threshold' ) ) &&
			access_has_global_level( $t_access_level );

		# this deviates from the behaviour of view_user_page.php, but it is more intuitive
		$t_is_same_user = $t_current_user_id === $p_user_id;

		$t_can_see_realname = access_has_project_level( config_get( 'show_user_realname_threshold' ) );
		$t_can_see_email = access_has_project_level( config_get( 'show_user_email_threshold' ) );

		if ( $t_is_same_user || $t_can_manage || $t_can_see_realname ) {
			$t_realname = user_get_realname( $p_user_id );

			if( !empty( $t_realname ) ) {
				$t_result['real_name'] = $t_realname;
			}
		if ( $t_is_same_user || $t_can_manage || $t_can_see_email ) {
			$t_email = user_get_email( $p_user_id );
			if( !empty( $t_email ) ) {
				$t_result['email'] = $t_email;
			}
CVE-2014-8986 (PHP, published 2014-11-24T15:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in the selection list in the filters in the Configuration Report page (adm_config_report.php) in MantisBT 1.2.13 through 1.2.17 allows remote administrators to inject arbitrary web script or HTML via a crafted config option, a different vulnerability than CVE-2014-8987.
Severity: LOW (CVSS v3 base score: )
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
adm_config_report.php
Commit message: Fix: adm_config_report.php filtering does not check config option is valid

I've left this throwing ERROR_GENERIC as the only time this should be able
to be hit is if we have invalid input to start with.


Vulnerable code:

Fixed code:

if( !is_blank( $t_filter_config_value ) && (int)$t_filter_config_value !== META_FILTER_NONE ) {
	// check that config value exists
	if( @config_get_global( $t_filter_config_value ) === null ) {
		$t_cookie_path = config_get( 'cookie_path' );
		gpc_clear_cookie( $t_cookie_name, $t_cookie_path );

		trigger_error( ERROR_GENERIC, ERROR );
	}
}
CVE-2014-9701 (PHP, published 2017-08-09T18:29Z)
Description: value: Cross-site scripting (XSS) vulnerability in MantisBT before 1.2.19 and 1.3.x before 1.3.0-beta.2 allows remote attackers to inject arbitrary web script or HTML via the url parameter to permalink_page.php.
Severity: MEDIUM (CVSS v3 base score: 6.5)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
core/string_api.php
Commit message: Fix URL redirection issue in login_page.php

The fix for issue #17648 failed to correct all cases of redirection.

Alejo Popovici discovered that the regex checking for URLs pointing to
other domains considered an URL with a single '/' as local, allowing
redirection e.g. to http:/google.com on certain browsers.

Fixes #17997 (CVE-2015-1042)


Vulnerable code:
		3 == $t_type && preg_match( '@(?:[^:]*)?://@', $t_url ) > 0 ) {

Fixed code:
		3 == $t_type && preg_match( '@(?:[^:]*)?:/*@', $t_url ) > 0 ) {
CVE-2015-5059 (PHP, published 2017-08-01T14:29Z)
Description: value: The "Project Documentation" feature in MantisBT 1.2.19 and earlier, when the threshold to access files ($g_view_proj_doc_threshold) is set to ANYBODY, allows remote authenticated users to download attachments linked to arbitrary private projects via a file id number in the file_id parameter to file_download.php.
Severity: LOW (CVSS v3 base score: 5.3)
Weakness: CWE-200 \u2014 Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
config_defaults_inc.php
Commit message: Change default threshold to view project doc to VIEWER

Previously it was ANYBODY, which would let any user download files from
any project including private ones, even when they are not part of the
team.

Fixes #19873


Vulnerable code:
$g_view_proj_doc_threshold = ANYBODY;

Fixed code:
 * Note: setting this to ANYBODY will let any user download attachments
 * from private projects, regardless of their being a member of it.
 * @see $g_enable_project_documentation
 * @see $g_upload_project_file_threshold
$g_view_proj_doc_threshold = VIEWER;
CVE-2016-5364 (PHP, published 2017-02-17T17:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in manage_custom_field_edit_page.php in MantisBT 1.2.19 and earlier allows remote attackers to inject arbitrary web script or HTML via the return parameter.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
core/html_api.php
manage_custom_field_edit_page.php
Commit message: Fix XSS in custom fields management

Kacper Szurek (http://security.szurek.pl/) discovered an XSS
vulnerability in Custom fields management pages, caused by unescaped
output of 'return URL' GPC parameter. His report describes two ways to
exploit this issue:

1. using 'accesskey' inside hidden input field (see [1]) reflects XSS to
   the administrator in manage_custom_field_edit_page.php when the
   keyboard shortcut is actioned
2. using 'javascript:' URI scheme executes the code when the user clicks
   the [Proceed] link on manage_custom_field_update.php after updating
   a custom field

This commit fixes both attack vectors:

- properly escape the return URL prior to printing it on the hidden form
  field
- let html_operation_successful() sanitize the URL before displaying
  it, just like html_meta_redirect() does. In this case, if the
  string contains an URI scheme, it will be replaced by 'index.php'

[1] http://blog.portswigger.net/2015/11/xss-in-hidden-input-fields.html

Fixes #20956


Vulnerable code:
	print_bracket_link( $p_redirect_url, lang_get( 'proceed' ) );
			<input type="hidden" name="return" value="<?php echo $f_return ?>" />

Fixed code:
	print_bracket_link( string_sanitize_url( $p_redirect_url ), lang_get( 'proceed' ) );
			<input type="hidden" name="return" value="<?php echo string_attribute( $f_return ); ?>" />
CVE-2016-6837 (PHP, published 2017-01-10T15:59Z)
Description: value: Cross-site scripting (XSS) vulnerability in MantisBT Filter API in MantisBT versions before 1.2.19, and versions 2.0.0-beta1, 1.3.0-beta1 allows remote attackers to inject arbitrary web script or HTML via the 'view_type' parameter.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
core/filter_api.php
Commit message: Fix XSS in view_all_bug_page.php

The value of the view_type parameter on the view_all_bug_page.php page
was not encoded before being displayed.

This vulnerability was discovered by Will Dollman of Netcraft Ltd.

Initial patch modified to use strict comparison per Will's suggestion.

Fixes #21611


Vulnerable code:

Fixed code:

	# Filter view type - ensure it's either 'simple' or 'advanced' (prevent XSS)
	if( $p_filter_arr['_view_type'] !== 'advanced' ) {
		$p_filter_arr['_view_type'] = 'simple';
	}
CVE-2017-12062 (PHP, published 2017-08-01T15:29Z)
Description: value: An XSS issue was discovered in manage_user_page.php in MantisBT 2.x before 2.5.2. The 'filter' field is not sanitized before being rendered in the Manage User page, allowing remote attackers to execute arbitrary JavaScript code if CSP is disabled.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
manage_user_page.php
Commit message: Fix XSS in manage_user_page.php (CVE-2017-12062)

trichimtrich (https://twitter.com/trichimtrich) reported this
vulnerability, allowing an attacker to inject arbitrary code through a
crafted 'filter' form variable.

Prevent the attack by sanitizing the variable before output.

Fixes #23166

Signed-off-by: Damien Regad <dregad@mantisbt.org>


Vulnerable code:
			<input type="hidden" name="filter" value="<?php echo $f_filter ?>" />

Fixed code:
			<input type="hidden" name="filter" value="<?php echo string_attribute( $f_filter ); ?>" />
CVE-2017-6797 (PHP, published 2017-03-10T00:59Z)
Description: value: A cross-site scripting (XSS) vulnerability in bug_change_status_page.php in MantisBT before 1.3.7 and 2.x before 2.2.1 allows remote attackers to inject arbitrary JavaScript via the 'action_type' parameter.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
bug_change_status_page.php
Commit message: Fix XSS in bug_change_status_page.php

The value of the change_type parameter was not encoded before being
displayed as a hidden input.

This vulnerability was reported by Etienne Landais.

Fixes #22486


Vulnerable code:
<input type="hidden" name="action_type" value="<?php echo $f_change_type; ?>" />

Fixed code:
<input type="hidden" name="action_type" value="<?php echo string_attribute( $f_change_type ); ?>" />
CVE-2017-6797 (PHP, published 2017-03-10T00:59Z)
Description: value: A cross-site scripting (XSS) vulnerability in bug_change_status_page.php in MantisBT before 1.3.7 and 2.x before 2.2.1 allows remote attackers to inject arbitrary JavaScript via the 'action_type' parameter.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/mantisbt/mantisbt
Files changed:
bug_change_status_page.php
Commit message: Fix XSS in bug_change_status_page.php

The value of the change_type parameter was not encoded before being
displayed as a hidden input.

This vulnerability was reported by Etienne Landais.

Fixes #22486


Vulnerable code:
	<input type="hidden" name="action_type" value="<?php echo $f_change_type; ?>" />

Fixed code:
	<input type="hidden" name="action_type" value="<?php echo string_attribute( $f_change_type ); ?>" />