Unauthenticated Arbitrary File Upload Vulnerability in Chaty Pro Plugin

Published 5 March 2025
Table of Contents

Chaty Pro

Unauthenticated Arbitrary File Upload

18K
CVSS 10.0

This blog post discusses about the findings on the Chaty Pro plugin. This vulnerability is fixed on version 3.3.4 and the vulnerable function didn’t exist on free version (Chaty) of the plugin.

If you are a Patchstack customer, you are protected from this vulnerability already, and no further action is required from you.

For plugin developers, we have security audit services and Enterprise API for hosting companies.

About the Chaty Pro Plugin

The Chaty Pro plugin, which according to our research has around 18,000 installations,is the Premium version of the Chaty plugin.It provides a chat button to communicate with customers and allows you to chat with your website visitors via your preferred channels like WhatsApp chat, Facebook Messenger, and more.

The security vulnerability

The plugin suffers from an arbitrary file upload vulnerability. As a result, an attacker can upload a malicious file to the system and take over the WordPress site by performing a series of HTTP requests.

This vulnerability occurred because the code that handles user input didn’t have any authorization or nonce check. An attacker can use the file upload functionality, which is also provided to the end user on the main page. Patchstack assigned CVE-2025-26776 to this vulnerability.

The main vulnerability existed in the function chaty_front_form_save_data:

function chaty_front_form_save_data() {
    // Snipped code...

    if (isset($_FILES['custom_fields']['tmp_name']) && !empty($_FILES['custom_fields']['tmp_name'])) {
        $custom_file_dir = array();
        foreach ($_FILES['custom_fields']['tmp_name'] as $key => $val1) {
            foreach ($val1 as $key2 => $sub_value) {
                $wp_upload_dir = wp_upload_dir();
                $path = $wp_upload_dir['basedir'] . '/chaty-attachments';

                if (!is_dir($path)) {
                    mkdir($path);
                }

                $unique_name = strtotime(gmdate("Y/m/d H:i:s")) . '-' . wp_rand(100, 1000);
                $upload_path = $path . '/' . $unique_name . '-' . basename($_FILES['custom_fields']['name'][$key][$key2]);

                $file_allowed = array(
                    "jpg", "jpeg", "png", "gif", "pdf", "doc", "docx", "ppt", "pptx",
                    "pps", "ppsx", "odt", "xls", "xlsx", "mp3", "mp4", "wav", "mpg",
                    "avi", "mov", "wmv", "3gp", "ogv"
                );

                $filename = $_FILES['custom_fields']['name'][$key][$key2];
                $file_ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));

                if (move_uploaded_file($sub_value, $upload_path)) {
                    $attachment_url = $wp_upload_dir['baseurl'] . '/chaty-attachments/' . 
                        $unique_name . '-' . basename($_FILES['custom_fields']['name'][$key][$key2]);

                    $postData['custom_fields'][$key][$postData['custom_fields'][$key]['slug']] = $attachment_url;
                    // Example HTTP Request to exploit:
                    $custom_file_dir[$key][] = $path . '/' . $unique_name . '-' . basename($_FILES['custom_fields']['name'][$key][$key2]);
                }
            }
        }
    }

    // Snipped code...
}

Although there is a variable called $file_allowed with a whitelist of extensions that should be allowed, it is never implemented in any part of the code. Uploaded file name contains the upload time and a random number between 100 and 1000, so it is possible to upload a malicious PHP file and access it by brute forcing possible file names around the upload time.

The patch

Instead of utilizing an insecure call to PHP’s move_uploaded_file() with unsanitized user data, the functionality that handles file uploads now utilizes wp_handle_upload() and properly checks the uploaded files extension and content.

Conclusion

Uploading files directly from users to the server always carries security risks. Both file extensions and file contents should be thoroughly validated and sanitized to prevent malicious uploads. Vendors should never rely on user-supplied file names, as they can be manipulated for attacks. Additionally, uploaded file names should be randomized and stored securely to prevent enumeration attacks, ensuring that sensitive user data remains protected from unauthorized access or brute-force attempts. Implementing proper access controls and restricting executable files can further enhance security.

Want to learn more about finding and fixing vulnerabilities?

Explore our Academy to master the art of finding and patching vulnerabilities within the WordPress ecosystem. Dive deep into detailed guides on various vulnerability types, from discovery tactics for researchers to robust fixes for developers. Join us and contribute to our growing knowledge base.

Timeline

9 December, 2024We found the vulnerabilities and reached out to the vendor regarding the vulnerability.
9 December, 2024Vendor provided a super fast patch proposal which needed more security hardening.
11 December, 2024Vendor provided the second patch proposal for the vulnerability.
11 February, 2025Provided patch solution released with version 3.3.4.
14 February, 2025Published the vulnerability to the Patchstack database.
5 March, 2025Security advisory article publicly released.

Help us make the Internet a safer place

Making the WordPress ecosystem more secure is a team effort, and we believe that plugin developers and security researchers should work together.

  • If you’re a plugin developer, join our mVDP program that makes it easier to report, manage and address vulnerabilities in your software.
  • If you’re a security researcher, join Patchstack Alliance to report vulnerabilities & earn rewards.

The latest in Security advisories

Looks like your browser is blocking our support chat widget. Turn off adblockers and reload the page.
crossmenu