CVE-2024-22018 Overview
A vulnerability has been identified in Node.js affecting users of the experimental permission model when the --allow-fs-read flag is used. This flaw arises from an inadequate permission model that fails to restrict file stats through the fs.lstat API. As a result, malicious actors can retrieve stats from files that they do not have explicit read access to.
This vulnerability affects all users using the experimental permission model in Node.js 20 and Node.js 21. It is important to note that at the time this CVE was issued, the permission model is an experimental feature of Node.js.
Critical Impact
Attackers can bypass file system permission restrictions to retrieve file metadata (stats) from files they should not have access to, potentially exposing sensitive information about the file system structure.
Affected Products
- Node.js 20 (with experimental permission model enabled)
- Node.js 21 (with experimental permission model enabled)
- Systems using --allow-fs-read flag with experimental permissions
Discovery Timeline
- 2024-07-10 - CVE CVE-2024-22018 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2024-22018
Vulnerability Analysis
This vulnerability represents an authorization bypass in Node.js's experimental permission model. When developers enable the experimental permission model with the --allow-fs-read flag, they expect granular control over which files an application can access. However, the permission enforcement mechanism fails to properly validate access when the fs.lstat API is invoked.
The fs.lstat function is designed to retrieve file statistics (such as file size, creation time, modification time, and file type) without following symbolic links. Under normal circumstances, this operation should be subject to the same permission checks as other file system operations. The vulnerability allows an attacker to call fs.lstat on arbitrary files, regardless of whether read access was explicitly granted for those files.
This information disclosure vulnerability requires local access to exploit, making it less severe than remote exploitation scenarios. However, the exposed file metadata could reveal sensitive information about the system's file structure, directory layouts, and file existence, which could be leveraged for further attacks.
Root Cause
The root cause of this vulnerability lies in incomplete permission validation within the Node.js experimental permission model. The permission enforcement layer properly restricts file read and write operations but fails to extend the same restrictions to the fs.lstat API. This oversight allows the API to bypass permission checks entirely, treating file stat operations as unrestricted regardless of the configured permissions.
The experimental nature of the permission model likely contributed to this gap in security controls, as the feature was still under active development and had not undergone comprehensive security hardening.
Attack Vector
The attack requires local access to the system where a vulnerable Node.js application is running. An attacker who can execute JavaScript code within the Node.js runtime can leverage the fs.lstat API to enumerate files and directories, retrieve file metadata, and gather reconnaissance information about the target system.
The attack flow involves:
- Gaining access to execute code within a Node.js application using the experimental permission model
- Calling fs.lstat on target file paths to retrieve file statistics
- Analyzing the returned metadata to map the file system structure or confirm existence of sensitive files
- Using gathered intelligence for subsequent attack stages
The vulnerability mechanism works by exploiting the gap in permission model enforcement. When an application runs with --allow-fs-read configured for specific paths, the permission model should prevent access to files outside those paths. However, fs.lstat calls bypass this restriction entirely, allowing unrestricted file stat operations. For detailed technical analysis, see the HackerOne Report #2145862.
Detection Methods for CVE-2024-22018
Indicators of Compromise
- Unusual patterns of fs.lstat calls targeting files outside permitted directories
- Node.js applications attempting to enumerate sensitive system directories
- Unexpected file system metadata queries from sandboxed or permission-restricted applications
Detection Strategies
- Monitor Node.js application logs for excessive or suspicious fs.lstat operations
- Implement application-level auditing for file system API calls in permission-restricted contexts
- Use SentinelOne's behavioral AI to detect anomalous file system enumeration patterns
- Deploy runtime application self-protection (RASP) to identify permission bypass attempts
Monitoring Recommendations
- Enable verbose logging for applications using the experimental permission model
- Audit all file system API usage in security-critical Node.js applications
- Implement centralized log collection for Node.js runtime events
- Configure alerts for unexpected file metadata access patterns
How to Mitigate CVE-2024-22018
Immediate Actions Required
- Assess whether your Node.js applications use the experimental permission model with --allow-fs-read
- Update Node.js to the latest patched version that addresses this vulnerability
- Consider disabling the experimental permission model until a patch is applied
- Review application code for reliance on permission model security guarantees
Patch Information
Users should upgrade to patched versions of Node.js 20 and Node.js 21. Consult the Openwall OSS Security Update and NetApp Security Advisory NTAP-20240816-0007 for specific version guidance and patch availability.
Workarounds
- Avoid using the experimental permission model for security-critical applications
- Implement additional application-level permission checks for file system operations
- Use containerization or OS-level sandboxing as an additional defense layer
- Restrict the execution environment of Node.js applications to limit file system access at the OS level
# Configuration example - Run Node.js without experimental permission model
# Instead of using --allow-fs-read, rely on OS-level permissions
node --experimental-permission --allow-fs-read=/app/data your-app.js
# Alternative: Use container-based isolation
docker run --read-only --mount type=bind,source=/app/data,target=/data node:20-slim node /app/your-app.js
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


