Is CVE-2024-11680 (ProjectSend Improper Authentication) being exploited in the wild?

What this CVE means for exploitation status

CISA’s KEV listing is the practical signal that matters here. For a remote, unauthenticated improper authentication flaw, “exploited in the wild” means defenders should treat the issue as active exposure, not a theoretical bug waiting for a proof-of-concept. In operational terms, the question shifts from “is it vulnerable?” to “is it still exposed and has anyone already touched it?”

For a ProjectSend deployment, the first check is whether the affected application is internet reachable, whether options.php is accessible as described, and whether any reverse proxy, WAF, or network segmentation actually reduces exposure. A KEV entry should immediately move this class of issue into emergency triage, because exploitation can begin before the normal patch cycle catches up.

Use the CISA Known Exploited Vulnerabilities Catalog as the authoritative source for exploitation status and remediation urgency, and confirm the record in the NIST National Vulnerability Database and CVE Program for the canonical vulnerability entry.

Why improper authentication becomes a high-risk access issue

This vulnerability is not just a configuration bug. Improper authentication on a remotely reachable function can let an attacker alter application settings without valid credentials, which can create a foothold for follow-on compromise, data exposure, or service abuse. The immediate danger is unauthorized control of application behavior; the downstream danger is that the altered configuration may weaken every other control around the system.

Because the flaw is triggered through crafted HTTP requests, it is especially dangerous in environments that assume only “logged-in” users can reach sensitive administrative actions. That assumption fails here. If an attacker can reach the endpoint, they may not need stolen credentials, MFA bypass, or social engineering at all.

For triage and prioritisation, the FIRST EPSS model can help rank urgency alongside KEV, while the Zero-Day and Exploited Vulnerabilities Guide is useful for understanding how to respond when active exploitation is already underway.

What to do if you cannot patch immediately

If patching must wait, the priority is to reduce reachable attack surface and make misuse visible. That means restricting access to the application path, tightening allowlists, reviewing any externally exposed administrative routes, and watching for unexpected changes to application configuration. When an exploit targets authentication logic, compensating controls are only useful if they block the exact path the attacker uses.

You should also review whether the application can be isolated from the internet, whether administrative functions can be separated from user-facing traffic, and whether monitoring can detect changes that should never happen outside a trusted admin workflow. If you cannot verify that the endpoint is unreachable, assume the risk remains active.

The Vulnerability Management Guide provides a useful triage model for emergency exceptions, validation, and remediation tracking, while the OWASP ASVS is a good benchmark for the authentication and access-control expectations that this kind of flaw violates.

Risk and Threat Considerations

Improper authentication flaws are attractive because they often collapse the normal trust boundary between anonymous traffic and administrative capability. If an attacker can send requests that the application treats as trusted, the next step is often configuration tampering, credential harvesting, or planting a more durable access path.

Failure mechanism: The application accepts a request path that should require authentication or stronger authorization, allowing unauthorized state change through ordinary HTTP traffic.

Impact: The attacker may alter security-relevant settings, weaken the application’s defenses, or use the misconfiguration as a stepping stone to broader compromise and persistence.

Practitioner Guidance

What to verify: Confirm whether the instance is reachable from untrusted networks, whether the vulnerable function is exposed, and whether configuration changes occurred during the exposure window. If you have logs, look for unusual requests to options.php and any unexplained changes to security-sensitive settings.

Escalation / exception: Treat this as emergency remediation if the system is internet-facing or supports production workflows. If it must stay online before patching, document the exception, narrow reachability as much as possible, and assign explicit ownership for continuous monitoring until the fix is in place.

Practitioner takeaway: For a KEV-listed improper authentication flaw, the right question is not whether exploitation is possible, but whether you can prove the application was unreachable or uncompromised before the next attacker gets there.

Related resources from NHI Mgmt Group

• Is CVE-2024-53704 (SonicWall SonicOS SSLVPN Improper Authentication) being exploited in the wild?
• How do you patch or mitigate CVE-2024-11680 (ProjectSend Improper Authentication)?
• CVE-2024-11680 (ProjectSend Improper Authentication)
• Is CVE-2024-5910 (Palo Alto Networks Expedition Missing Authentication) being exploited in the wild?