CVE-2021-21290 Overview
CVE-2021-21290 is an information disclosure vulnerability in Netty, an open-source asynchronous event-driven network application framework widely used for developing high-performance protocol servers and clients. The vulnerability exists in Netty's multipart decoders on Unix-like systems, where insecure handling of temporary files can lead to local information disclosure when temporary storage of uploads on disk is enabled.
Critical Impact
Local attackers on Unix-like systems can read sensitive information from temporary files created by Netty's multipart decoders due to overly permissive default file permissions, potentially exposing uploaded data to unauthorized users.
Affected Products
- Netty versions prior to 4.1.59.Final
- Debian Linux 9.0 and 10.0
- Quarkus (versions using vulnerable Netty)
- Oracle Banking Corporate Lending Process Management (14.2.0, 14.3.0, 14.5.0)
- Oracle Banking Credit Facilities Process Management (14.2.0, 14.3.0, 14.5.0)
- Oracle Banking Trade Finance Process Management (14.2.0, 14.3.0, 14.5.0)
- Oracle Communications BRM - Elastic Charging Engine 12.0.0.3
- Oracle Communications Design Studio 7.4.2
- Oracle Communications Messaging Server 8.1
- Oracle NoSQL Database
- NetApp Active IQ Unified Manager (Linux and Windows)
- NetApp Cloud Secure Agent
- NetApp SnapCenter
Discovery Timeline
- 2021-02-08 - CVE-2021-21290 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2021-21290
Vulnerability Analysis
This vulnerability stems from insecure file permission handling in Netty's AbstractDiskHttpData class. On Unix-like systems, the system temporary directory (/tmp) is shared between all users. When Netty's multipart decoders write uploaded data to temporary files using Java's File.createTempFile() method, these files are created with default permissions of -rw-r--r-- (644), making them readable by all local users on the system.
The vulnerability specifically impacts applications that use Netty's HTTP multipart handling with disk-based temporary storage enabled. When sensitive data such as authentication tokens, user uploads, or other confidential information is written to these temporary files, any local user can read the contents before the files are cleaned up. This represents a significant confidentiality breach in multi-user environments.
It's important to note that modern macOS operating systems are not affected by this vulnerability due to different default temporary directory permissions.
Root Cause
The root cause lies in the use of the standard Java File.createTempFile() API, which on Unix-like systems creates files with world-readable permissions by default. The AbstractDiskHttpData class in Netty's HTTP codec did not explicitly set restrictive file permissions when creating temporary files for storing multipart HTTP data. Similarly, the NativeLibraryLoader class used the same insecure pattern when extracting native libraries to temporary files.
Attack Vector
This is a local attack vector requiring the attacker to have existing access to the same Unix-like system where the vulnerable Netty application is running. The attack proceeds as follows:
- An attacker with local system access monitors the system temporary directory (/tmp or configured java.io.tmpdir)
- When a legitimate user uploads data through a Netty-based application with disk storage enabled, the data is written to a world-readable temporary file
- The attacker reads the sensitive uploaded data from the temporary file before it is deleted
- No special privileges are required beyond basic local user access
// Security patch showing migration from File.createTempFile to secure alternative
// Source: https://github.com/netty/netty/commit/c735357bf29d07856ad171c6611a2e1a0e0000ec
// Before (vulnerable):
// tmpFile = File.createTempFile(prefix, suffix, WORKDIR);
// After (fixed in NativeLibraryLoader.java):
tmpFile = PlatformDependent.createTempFile(prefix, suffix, WORKDIR);
The fix uses Files.createTempFile() which creates files with permissions restricted to the owner only, wrapped through PlatformDependent.createTempFile() for consistent secure behavior across platforms.
Detection Methods for CVE-2021-21290
Indicators of Compromise
- Unusual file access patterns in the system temporary directory (/tmp or custom java.io.tmpdir)
- Multiple users reading temporary files with patterns matching Netty's naming conventions
- Unexpected processes monitoring or scanning the temporary directory
- Evidence of file enumeration activities targeting Java application temporary files
Detection Strategies
- Monitor file access events in system temporary directories for unauthorized read operations by non-owning users
- Implement file integrity monitoring on temporary directories to detect suspicious access patterns
- Review application logs for multipart upload activities and correlate with file system access logs
- Use endpoint detection tools to identify processes performing directory enumeration on /tmp
- Audit Java applications for use of vulnerable Netty versions in dependency trees
Monitoring Recommendations
- Enable file access auditing on Unix-like systems for the /tmp directory and any custom temporary directories
- Configure SentinelOne behavioral AI to detect unusual file access patterns in shared directories
- Implement alerting for any non-owner read access to temporary files created by Java applications
- Monitor for rapid sequential file reads in temporary directories that may indicate automated data exfiltration
How to Mitigate CVE-2021-21290
Immediate Actions Required
- Upgrade Netty to version 4.1.59.Final or later immediately
- Audit all applications using Netty as a dependency and update accordingly
- Review temporary directory permissions on affected systems
- Consider implementing additional access controls on system temporary directories
- For Java applications that cannot be immediately updated, configure a dedicated secure temporary directory
Patch Information
The vulnerability has been fixed in Netty version 4.1.59.Final. The fix replaces the use of File.createTempFile() with Files.createTempFile() through the PlatformDependent.createTempFile() wrapper, which creates files with owner-only permissions on Unix-like systems. The patch is available via the GitHub commit and the GitHub Security Advisory.
Oracle has addressed this vulnerability in multiple Critical Patch Updates including April 2021, October 2021, and April 2022 for affected Oracle products.
Workarounds
- Specify a custom temporary directory with restricted permissions using the -Djava.io.tmpdir JVM argument when starting the application
- Use DefaultHttpDataFactory.setBaseDir(...) to configure Netty to use a directory that is only readable by the current user
- Implement directory-level access controls using file system permissions or ACLs to restrict the temporary directory
- On systemd-based systems, use PrivateTmp=true in service units to provide isolated temporary directories
# Configuration example - Set secure temporary directory with restricted permissions
# Create a dedicated temporary directory for the application
mkdir -p /opt/app/secure-tmp
chown appuser:appgroup /opt/app/secure-tmp
chmod 700 /opt/app/secure-tmp
# Start Java application with custom tmpdir
java -Djava.io.tmpdir=/opt/app/secure-tmp -jar mynettyapp.jar
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


