CVE-2024-20481
A vulnerability in the Remote Access VPN (RAVPN) service of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software…
- Severity
- 5.8 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 15.87%
- Chance of exploitation in the next 30 days. Higher than 96.89% of scored vulnerabilities.
- Known exploited
- Yes
- In CISA's catalog since Oct 24, 2024
- Weakness
- CWE-772 Missing Release of Resource after Effective Lifetime
- CWE-772 Missing Release of Resource after Effective Lifetime
- Fix
- None yet
- No fixed version published
Description
A vulnerability in the Remote Access VPN (RAVPN) service of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause a denial of service (DoS) of the RAVPN service. This vulnerability is due to resource exhaustion. An attacker could exploit this vulnerability by sending a large number of VPN authentication requests to an affected device. A successful exploit could allow the attacker to exhaust resources, resulting in a DoS of the RAVPN service on the affected device. Depending on the impact of the attack, a reload of the device may be required to restore the RAVPN service. Services that are not related to VPN are not affected. Cisco Talos discussed these attacks in the blog post Large-scale brute-force activity targeting VPNs, SSH services with commonly used login credentials.
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.1 5.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
Weakness
CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Advisories
Other links
Timeline
- Published
- Added to CISA's Known Exploited Vulnerabilities catalog
- Remediation due for U.S. federal agencies
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| PYSEC-2026-4007 vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders… | Medium | Same weakness, CWE-772 |
| GHSA-pmjh-fq2x-6v4x undici vulnerable to Denial of Service via orphaned RetryHandler response body | Medium | Same weakness, CWE-772 |
| GHSA-3p27-qvp9-27qf Wasmtime has a leak in WASIp1 `fd_renumber` implementation | Medium | Same weakness, CWE-772 |
| GHSA-fw38-pc54-jvx9 Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS | Medium | Same weakness, CWE-772 |
| GHSA-vgwf-h737-ff37 golang.org/x/crypto: Invoking client can cause server deadlock on unexpected responses | Critical | Same weakness, CWE-772 |
| GHSA-xxh7-fcf3-rj7f The Eclipse Jetty Server Artifact has a Gzip request memory leak | High | Same weakness, CWE-772 |
| GHSA-xw98-5q62-jx94 Traefik: tcp router clears read deadlines before tls forwarding, enabling stalled handshakes (Slowloris DOS) | High | Same weakness, CWE-772 |
| GHSA-9fm9-hp7p-53mf Hackney fails to properly release HTTP connections to the pool | Low | Same weakness, CWE-772 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor