CVE-2024-11680: ProjectSend unauthenticated authentication bypass, actively exploited
The short version: ProjectSend — an open-source file-sharing web app — has an improper-authentication flaw (CVE-2024-11680) that lets a remote, unauthenticated attacker send crafted requests to options.php and change the application's configuration. From there they can enable registration, create accounts, upload web shells, and inject malicious JavaScript. It scores 9.8, it's been exploited at scale, and it's in CISA's KEV catalog. If you run ProjectSend before r1720, treat this as patch-now.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 91.56% · 99.8th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation due 2024-12-24 (added 2024-12-03) |
| Known exploited? | Yes — widespread exploitation reported |
| Vulnerability type | CWE-306 missing authentication for a critical function → unauthorized config change → account creation / web shell upload |
| Requires authenticated session? | No — pre-authentication |
| Affected | ProjectSend versions before r1720 |
| Fixed in | r1720 |
What you need to know
ProjectSend gates certain actions behind an authentication check that simply isn't enforced where it needs to be. By sending crafted HTTP requests to options.php, an unauthenticated attacker can modify the application's stored configuration.
That's the whole game, because configuration is control. Flip the right options and an attacker can turn on self-registration and create their own accounts, change the landing/header content to serve malicious JavaScript to every visitor, or abuse upload paths to drop a web shell — arbitrary code execution on the host.
- It's pre-authentication and automatable. No credential, no user interaction; the requests are simple enough to spray across the internet.
- It's already operational. ProjectSend instances are internet-facing by design, and this flaw has been exploited broadly since disclosure.
How serious we see it
High — the 9.8 is earned here.
Unauthenticated, network-reachable, and leading straight to account creation and code execution on an internet-facing app is top-of-queue. The bounded, reassuring part is that it's narrow and fixable: it affects ProjectSend builds before r1720, the fix exists, and exposure is quick to confirm. The catch, as with any mass-exploited flaw, is that patched and clean are separate questions — if you were exposed, check for what may already have been planted.
Recommendations
Straight from the vendor's fix and CISA:
- Patch now. Upgrade to ProjectSend r1720 or later.
- Hunt for compromise. Look for unexpected user accounts, new or modified files in upload/web directories, unfamiliar web shells, and injected JavaScript in headers/templates.
- If you find evidence, respond. Remove web shells, rotate credentials and secrets, and rebuild if integrity is in doubt.
- Reduce exposure. Restrict the instance to trusted networks or behind authentication upstream until patched; don't leave the admin surface open to the world.
- Confirm your exposure first. Verify whether you run ProjectSend at all, and which revision.
How BreachRisk sees it
BreachRisk answers the first question — do we have an exposed, affected ProjectSend? — from the outside in. Starting from little more than your domain, it discovers internet-facing ProjectSend login and detection surfaces, fingerprints the revision, and flags exposure tied to this KEV-listed, actively exploited flaw, surfaced at the top of your results because it's in KEV. We detect and flag the exposed, affected instance; we don't modify your app's content or plant a test account to prove it.
That outside-in view is exactly what you want when a flaw is being sprayed across the internet: the exposed instance is already mapped, so you can go straight to patch-and-verify.