ProjectSend is an open-source file-sharing web application. The project is moderately popular, with almost 1,500 GitHub stars and more than 4,000 instances indexed by Censys. Although the CVE for this vulnerability was only published today (November 26), the patch has been publicly available for over a year (May 16, 2023). Since the patch release, multiple exploits have been published by Synactiv, Project Discovery (Nuclei), and Rapid7 (Metasploit). The lack of a CVE is an oversight that stands out, particularly given Rapid7’s status as a CNA (CVE Numbering Authority) with Researcher and Open Source scope.

Vulnerability Timeline

1. January 19, 2023

   Synactiv discloses to ProjectSend

2. May 16, 2023

   ProjectSend patches the vulnerability

3. July 19, 2024

   Synactiv releases an advisory

4. August 3, 2024

   ProjectSend releases the official patch in r1720

5. August 30, 2024

   A Metasploit pull request is opened

6. September 3, 2024

   A Nuclei pull request is opened

7. November 25, 2024

   VulnCheck assigns CVE-2024-11680

Exploited in the Wild

VulnCheck noticed that public-facing ProjectSend servers had started to change their landing page titles to long, random-ish strings. Some of the “random” names have larger groupings, for example:

These long and random-ish names are in line with how both Nuclei and Metasploit implement their vulnerability testing logic. Both exploit tools modify the victim’s configuration file to alter the sitename (and therefore HTTP title) with a random value.

Nuclei exploit check:

- raw:
    - |
        POST /options.php HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/x-www-form-urlencoded

        csrf_token={{csrf}}&section=general&this_install_title={{string}}

Metasploit exploit check:

# Test if the instance is vulnerable by trying to change its title
params = {
    'csrf_token' => csrf_token,
    'section' => 'general',
    'this_install_title' => random_new_title
}
res = send_request_cgi({
    'method' => 'POST',
    'uri' => normalize_uri(datastore['TARGETURI'], 'options.php'),
    'keep_cookie' => true,
    'vars_post' => params
})

This is a very heavy-handed “test” (although in Metasploit’s defense, they at least try to restore the original value) and not something any “researcher” should actually be doing. Especially considering the application's publication date is embedded right in the landing page (e.g. you can determine if a vulnerable version is being used without exploiting the target). Regardless, these random titles started to appear in September, just as the Metasploit and Nuclei exploits were made public.

While the endpoint might be fairly generic (options.php), our friend over at GreyNoise also appear to index more than one hundred IP addresses hitting that URI.

What’s more concerning is that attackers don’t appear to stop at “testing.” One of the next steps in exploitation involves enabling user registration (a non-default setting) to gain post-authentication privileges. When this setting is activated, the text on the landing page changes to prompt users to register an account. An example from a victim site follows (the URL and branding of been blocked out):

Given how widespread we are seeing this setting enabled, we think this is likely a bigger problem than “researchers intrusively checking for vulnerable versions.” We are likely in the “attackers installing webshells” territory (technically, the vulnerability also allows the attacker to embed malicious JavaScript, too, which could be an interesting and different attack scenario).

If an attacker has uploaded a webshell, it can be found in a predictable location in upload/files/ off of the webroot. The files are assigned a predictable name that might help identify exploit timelines as well: {posix timestamp of upload}-{sha1 username}-{original file name}.{original extension}.

Additionally, these files are not meant to be directly accessed - downloads are intended to go through an entirely different endpoint. Reviewing the server access logs for direct access to upload/files/ will likely be useful in determining exploitation.

Patch Adoption

The VulnCheck Initial Access team developed a scanner to fingerprint the versions of internet-facing systems. Using the Shodan data, we found approximately 1% were using the patched version (r1750). 55% are using r1605 (released October 2022), 44% are using an unnamed release (released April 2023), and the remaining 1% are using the patched r1750.

Given the timeline, evidence of exploitation, and lack of patch adoption, we assume that exploitation is likely widespread. And if not now, then in the near future considering the abysmal patching rates.

Conclusion

The ProjectSend vulnerability, now identified as CVE-2024-11680, has been publicly known for some time. A patch was released on May 16, 2023, and various exploits have been available for months. However, due to the absence of a CVE assignment, centralized documentation was lacking. With the CVE now assigned and evidence of ongoing exploitation, it is crucial for security companies to assess their customers' exposure, implement necessary remediations, and conduct incident response activities as needed.

About VulnCheck

The VulnCheck Initial Access team is always on the lookout for new exploitation in the wild. For more research like this, see our blogs, PaperCut Exploitation, Fileless Remote Code Execution on Juniper Firewalls , and Does Confluence Dream of Shells?

Sign up to our website today to get free access to our VulnCheck KEV and request a trial of our Initial Access Intelligence and Exploit & Vulnerability Intelligence products.