Cloudanix VulnDB

CVE-2024-11680

Critical · 9.8 CISA KEV

CVSS

9.8

EPSS

91.8%

Published

Nov 26, 2024

CISA due date

Dec 24, 2024

Cloudanix analysis

Act now SSVC: Attend

A flaw in a file-sharing application can let outsiders change settings, create accounts, and plant malicious files without logging in.

Active In The Wild
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Trivial
Impact
Full Compromise
Component
Application
Class
Authentication Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

ProjectSend versions prior to r1720 fail to enforce authentication properly on the options.php configuration endpoint. A remote unauthenticated attacker can send crafted HTTP requests that change application settings without a valid session. Once configuration is modified, the attacker can enable or abuse account registration, create unauthorized users, alter upload behavior, upload server-side scripts such as webshells, and inject malicious JavaScript into pages served by the application. In practical terms, the flaw can progress from authentication bypass to persistent administrative control, stored cross-site scripting, arbitrary file upload, and potential remote code execution depending on server configuration.

Why it matters to the business

This is a critical, actively exploited internet-facing file-sharing application vulnerability with a very high EPSS score and inclusion in CISA KEV, meaning exposed systems should be treated as likely targets. Successful exploitation can lead to data theft from shared files, unauthorized account access, website defacement, credential harvesting, malware staging, lateral movement from the web server, and operational disruption. The CISA remediation due date of 2024-12-24 has passed, so any remaining exposure represents an overdue high-priority risk.

How an attack unfolds

An attacker first identifies an exposed ProjectSend instance running a version earlier than r1720. They then send unauthenticated crafted HTTP requests directly to options.php, abusing missing or improper authentication checks to change application configuration. With configuration control, the attacker may enable unauthorized user creation, create an account they control, alter upload-related settings, or embed malicious JavaScript into the application. The attacker can then log in with the created account or continue abusing the configuration change to upload a webshell or other malicious file. If uploaded server-side code is executable by the web server, the attacker can issue commands through the webshell, maintain persistence, access stored files, steal credentials or tokens available to the application, and use the compromised host as a foothold for further activity. Public exploitation has been observed in the wild, so opportunistic scanning and automated exploitation should be expected.

How to fix it

Upgrade ProjectSend to r1720 or later immediately. For source-based deployments, update to a release containing commit 01892437a4b133f84864b0fb83ddf85efac2d5a9 or a later trusted upstream commit. If using distribution packages, apply the vendor-fixed package where applicable, including spip on Ubuntu 18.04 LTS fixed in 3.1.4-4~deb9u3build0.18.04.1 if that package is actually present and relevant in the environment. Remove public exposure where not required, place the application behind a VPN or access gateway, and restrict administrative/configuration endpoints by network controls. Review and reset application configuration to known-good values after patching, because exploitation can persist through modified settings. Remove unauthorized users, rotate application administrator credentials, rotate database and storage credentials available to the application, and inspect upload directories for executable or suspicious files. Harden the web server so uploaded directories cannot execute PHP or other server-side code, and enforce allow-listed upload file types.

How to confirm the fix worked

Confirm the running ProjectSend version is r1720 or later, or verify the deployed code includes commit 01892437a4b133f84864b0fb83ddf85efac2d5a9 or a later fix. Attempt to access or submit changes to options.php without an authenticated administrative session in a controlled test; the request should be rejected or redirected and must not alter configuration. Review application settings for unexpected changes, especially registration, upload, branding, custom HTML, and JavaScript-related options. Confirm no unknown users or recently created administrative accounts exist. Validate that uploaded directories do not execute server-side scripts by placing a harmless test file with a script extension and confirming it is not executed. Check web server access logs for unauthenticated or unusual requests to options.php before and after remediation. Re-scan externally exposed assets to ensure vulnerable ProjectSend instances are no longer reachable or are upgraded.

Typical attack path

  1. Scan the internet or internal address space for exposed ProjectSend instances.
  2. Fingerprint the application version or infer vulnerability from accessible ProjectSend endpoints.
  3. Send unauthenticated crafted HTTP requests to options.php to modify application configuration.
  4. Enable or abuse account creation and create an attacker-controlled account.
  5. Modify upload behavior or use available upload functionality to place malicious content, including JavaScript or a webshell.
  6. Access the uploaded malicious file or injected script to execute actions in the application or on the server.
  7. Persist through new accounts, modified settings, webshells, or additional backdoors.
  8. Exfiltrate files, harvest credentials, pivot to adjacent systems, or stage additional malware.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF logs, application logs, file integrity monitoring, and endpoint telemetry for evidence of exploitation. Prioritize requests to options.php from unauthenticated users, unfamiliar IP addresses, scanners, or requests lacking normal referrers/session cookies. Look for POST requests to options.php followed by changes in application behavior, new user creation, uploads of executable files, or access to newly uploaded PHP files. Inspect ProjectSend upload and temporary directories for webshells, recently modified scripts, files with double extensions, obfuscated code, or small PHP files containing command execution functions. Review application configuration for unexpected registration enablement, upload policy changes, injected JavaScript, external script references, or altered site branding/content. Correlate suspicious options.php activity with subsequent requests to uploaded files, outbound network connections from the web server, unusual child processes spawned by the web service account, and credential or data access anomalies. Because exploitation is active in the wild, search historical logs back to at least the public disclosure date, and longer if internet exposure predates patching.

  • POST /options.php
  • GET /options.php
  • /options.php
  • /upload/files/
  • /upload/files/*.php
  • /upload/temp/
  • /upload/temp/*.php
  • .php?cmd=
  • shell.php
  • cmd.php
  • webshell.php
  • FilesMan
  • WSO
  • c99shell
  • r57shell
  • base64_decode(
  • gzinflate(
  • shell_exec(
  • passthru(
  • system($_
  • eval($_
  • assert($_
  • <script src="http://
  • <script src="https://

What your security team should do

  • Treat all internet-exposed ProjectSend instances prior to r1720 as potentially compromised, not merely vulnerable.
  • Patch or upgrade immediately to r1720 or later; this vulnerability is in CISA KEV, actively exploited, and the remediation deadline has passed.
  • Temporarily restrict access to ProjectSend to trusted networks or an access gateway until patching and compromise assessment are complete.
  • Review web server logs for unauthenticated POST requests to options.php and subsequent uploads or newly created accounts.
  • Hunt for webshells and executable files in upload directories, especially PHP files with recent modification times.
  • Audit application users and remove unknown, recently created, or unexpectedly privileged accounts.
  • Reset ProjectSend configuration to a trusted baseline and remove injected JavaScript, custom HTML, or suspicious external references.
  • Rotate administrator passwords and any secrets accessible to the application, including database, SMTP, storage, and API credentials.
  • Disable script execution in upload paths at the web server level and enforce strict file type validation.
  • If evidence of webshell execution or server compromise is found, perform full incident response including host isolation, forensic imaging, credential rotation, and lateral movement investigation.

The record

ProjectSend versions prior to r1720 are affected by an improper authentication vulnerability. Remote, unauthenticated attackers can exploit this flaw by sending crafted HTTP requests to options.php, enabling unauthorized modification of the application's configuration. Successful exploitation allows attackers to create accounts, upload webshells, and embed malicious JavaScript.

Affected packages

Ecosystem Package Introduced Fixed