Summary
A path traversal vulnerability in Node-RED's local-filesystem library storage module allows authenticated users to access files outside the intended library directory. Depending on permissions, an attacker may read arbitrary files or write attacker-controlled content to sensitive locations, which could enable remote code execution.
Affected context
The vulnerability occurs in Node-RED deployments using the local-filesystem library storage module and exposing the library API endpoints. It affects requests that pass user-controlled path data to library entry retrieval or storage operations without sufficient normalization and directory-containment enforcement. Read access may be possible with a read-only-scoped authenticated token, while arbitrary file writes require the corresponding write permission.
Exploit preconditions
- Attack surface: The authenticated library API exposed through
GETandPOSTrequests under/library/:lib/:type/*path - Required access: Authentication is required; read access may be sufficient for file disclosure, while write access is required for file modification
- Trigger point: Library entry retrieval or saving through the local-filesystem storage implementation
- Why exploitation is possible: User-controlled path components are combined with the library directory without reliable traversal filtering, canonical containment checks, or prefix verification
Why this happens
The underlying bug is improper restriction of externally influenced file paths, mapping to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The storage implementation uses a user-controlled path when constructing filesystem locations but does not consistently canonicalize the result and verify that it remains beneath the intended library root. This allows path resolution to escape the configured storage boundary.
Potential impact
- Attackers may read sensitive files accessible to the Node-RED process
- Attackers may overwrite or create files outside the intended library directory
- Application configuration, credentials, or source files could be exposed or altered
- Persistence mechanisms such as authorized keys or scheduled tasks could be modified
- The Node-RED host may be compromised, depending on process privileges and filesystem controls
General mitigation guidance
Mitigation generally focuses on treating all path components as untrusted and enforcing the storage boundary after path resolution.
Common defensive patterns include:
- Canonicalizing candidate paths before filesystem access
- Verifying that resolved paths remain within the configured library root
- Rejecting traversal components and ambiguous path encodings
- Using filesystem APIs that constrain operations to an approved directory where available
- Separating read and write permissions and applying least privilege to service accounts
- Restricting write access to sensitive host locations and using read-only filesystem controls where practical
- Limiting the Node-RED process's access to credentials, SSH configuration, scheduled-task directories, and other high-impact paths
- Enforcing authentication, narrowly scoped tokens, and network-level access controls for library endpoints
How teams detect issues like this
Detection can include static analysis and review of filesystem APIs that concatenate or join request-derived values with directory paths. Code review should look for missing canonicalization, containment checks, encoded traversal handling, and inconsistent validation between read and write operations.
Runtime monitoring may identify unusual library API requests, access to unexpected filesystem locations, changes to sensitive files, or Node-RED processes creating files outside approved directories. CI and policy checks can require centralized safe-path helpers and reject direct use of request path parameters in filesystem operations. Automated security review tools may help flag these patterns, but findings should be validated against deployment permissions.
