GHSA-wph7-x527-w3h5 BIT-tomcat-2021-42340 CVE-2021-42340

Missing Release of Resource after Effective Lifetime in Apache Tomcat

High Maven

Severity: 7.5 / 10; High · CVSS 3.1
Exploit chance (EPSS): 11.80%; Chance of exploitation in the next 30 days. Higher than 96.08% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-772 Missing Release of Resource after Effective Lifetime
Fix: 10.1.0-M6; Upgrade org.apache.tomcat:tomcat to this version or later

Description

The fix for bug 63362 present in Apache Tomcat 10.1.0-M1 to 10.1.0-M5, 10.0.0-M1 to 10.0.11, 9.0.40 to 9.0.53 and 8.5.60 to 8.5.71 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError.

Affected versions

Maven

Package	Vulnerable	Fixed in
org.apache.tomcat:tomcat	`>= 10.1.0-M1, < 10.1.0-M6`	`10.1.0-M6`
org.apache.tomcat:tomcat	`>= 10.0.0-M1, < 10.0.12`	`10.0.12`
org.apache.tomcat:tomcat	`>= 9.0.40, < 9.0.54`	`9.0.54`
org.apache.tomcat:tomcat	`>= 8.5.60, < 8.5.72`	`8.5.72`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

org.apache.tomcat:tomcat Maven → `10.1.0-M6`

maven

<dependency><groupId>org.apache.tomcat</groupId><artifactId>tomcat</artifactId><version>10.1.0-M6</version></dependency>

gradle

implementation("org.apache.tomcat:tomcat:10.1.0-M6")

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: None
Availability: High

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).

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2021-42340

Packages

github.com/apache/tomcat

Timeline

Oct 15, 2021 Published
Mar 11, 2024 Last updated by the source
Nov 1, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-69r9-qgr7-g2wj Apache Tomcat Missing Encryption of Sensitive Data vulnerability	High Known exploited	Also affects org.apache.tomcat:tomcat
GHSA-h3x4-894j-xpx5 Apache Tomcat's FORM authentication process has an Incorrect Authorization vulnerability	Critical	Also affects org.apache.tomcat:tomcat
GHSA-9xv2-5v5q-p794 Apache Tomcat's DIGEST authenticator has an Authentication Bypass by Capture-replay vulnerability	Critical	Also affects org.apache.tomcat:tomcat
GHSA-gcx9-497g-6cp6 Apache Tomcat has an Improper Access Control, Incorrect Authorization vulnerability	Critical	Also affects org.apache.tomcat:tomcat
GHSA-5m62-pw8w-7w9f Apache Tomcat - Security constraints not correctly applied	Critical	Also affects org.apache.tomcat:tomcat
GHSA-9m89-8frq-c98c Apache Tomcat - AJP secret compared in non-constant time	Low	Also affects org.apache.tomcat:tomcat
GHSA-5mp6-jrq3-r938 Apache Tomcat: LockOutRealm treats user names as case-sensitive	High	Also affects org.apache.tomcat:tomcat
GHSA-h6fc-48rj-7qqh Apache Tomcat - Digest authenticator will authenticate any unknown user	Critical	Also affects org.apache.tomcat:tomcat

Is this in your code?

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