Dotproject » Dotproject : Security Vulnerabilities, CVEs,

Multiple cross-site scripting (XSS) vulnerabilities in dotProject before 2.1.7 allow remote attackers to inject arbitrary web script or HTML via the (1) callback parameter in a color_selector action, (2) field parameter in a date_format action, or (3) company_name parameter in an addedit action to index.php. NOTE: the date parameter vector is already covered by CVE-2008-3886.

Multiple SQL injection vulnerabilities in dotProject before 2.1.7 allow remote authenticated administrators to execute arbitrary SQL commands via the (1) search_string or (2) where parameter in a contacts action, (3) dept_id parameter in a departments action, (4) project_id[] parameter in a project action, or (5) company_id parameter in a system action to index.php. NOTE: this can be leveraged using CSRF to allow remote attackers to execute arbitrary SQL commands.

dotproject 2.1.4 allows remote attackers to obtain sensitive information via a direct request to a .php file, which reveals the installation path in an error message, as demonstrated by style/dp-grey-theme/footer.php and certain other files.

dotProject before 2.1.2 does not properly restrict access to administrative pages, which allows remote attackers to gain privileges. NOTE: some of these details are obtained from third party information.

Multiple SQL injection vulnerabilities in index.php in dotProject 2.1.2 allow (1) remote authenticated users to execute arbitrary SQL commands via the tab parameter in a projects action, and (2) remote authenticated administrators to execute arbitrary SQL commands via the user_id parameter in a viewuser action.

Multiple cross-site scripting (XSS) vulnerabilities in index.php in dotProject 2.1.2 allow remote attackers to inject arbitrary web script or HTML via (1) the inactive parameter in a tasks action, (2) the date parameter in a calendar day_view action, (3) the callback parameter in a public calendar action, or (4) the type parameter in a ticketsmith action.

dotProject before 2.1 does not properly check privileges when invoking the Companies module, which allows remote attackers to access this module via a crafted URL. NOTE: some of these details are obtained from third party information.

Cross-site scripting (XSS) vulnerability in dotProject before 2.1 RC2 allows remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2006-2851 and CVE-2006-3240.

PHP remote file inclusion vulnerability in classes/query.class.php in dotProject 2.0.4 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the baseDir parameter.

Cross-site scripting (XSS) vulnerability in classes/ui.class.php in dotProject 2.0.3 and earlier allows remote attackers to inject arbitrary web script or HTML via the login parameter.

Cross-site scripting (XSS) vulnerability in index.php in dotProject 2.0.2 and earlier allows remote attackers to inject arbitrary web script or HTML via unspecified parameters, which are not properly handled when the client is using Internet Explorer.

dotProject 2.0.1 and earlier leaves (1) phpinfo.php and (2) check.php accessible under the /docs/ directory after installation, which allows remote attackers to obtain sensitive configuration information. NOTE: the vendor disputes this issue, saying that it could only occur if the administrator ignores the installation instructions as well as warnings generated by check.php

Multiple PHP remote file include vulnerabilities in dotProject 2.0.1 and earlier, when register_globals is enabled, allow remote attackers to execute arbitrary commands via the baseDir parameter in (1) db_adodb.php, (2) db_connect.php, (3) session.php, (4) vw_usr_roles.php, (5) calendar.php, (6) date_format.php, and (7) tasks/gantt.php; and the dPconfig[root_dir] parameter in (8) projects/gantt.php, (9) gantt2.php, and (10) vw_files.php. NOTE: the vendor disputes this issue, stating that the product documentation clearly recommends that the system administrator disable register_globals, and that the check.php script warns against this setting. Also, the vendor says that the protection.php/siteurl vector is incorrect because protection.php does not exist in the product

dotProject 2.0.1 and earlier allows remote attackers to obtain sensitive information via direct requests with an invalid baseDir to certain PHP scripts in the db directory, which reveal the path in an error message. NOTE: the vendor disputes this issue, saying that it could only occur if the administrator ignores the installation instructions as well as warnings generated by check.php

index.php in dotProject 0.2.1.5 allows remote attackers to bypass authentication via a cookie or URL with the user_cookie parameter set to 1.