Summary
A path traversal flaw in the wakaru CLI unbundling feature allows crafted module filenames to escape the intended output directory after incomplete sanitization.
If a user runs wakaru --unpack on a malicious bundle, an attacker-controlled filename may write files outside the target directory and, in some environments, lead to code execution.
A path traversal flaw in the wakaru CLI unbundling feature allows crafted module filenames to escape the intended output directory after incomplete sanitization.
If a user runs wakaru --unpack on a malicious bundle, an attacker-controlled filename may write files outside the target directory and, in some environments, lead to code execution.
Affected context
This vulnerability affects projects and build pipelines that use @wakaru/cli to unpack JavaScript bundles with --unpack, and that process bundle content from untrusted or semi-trusted sources.
The issue arises when the CLI derives output paths directly from module filenames contained in the bundle and relies on a single round of sanitization.
Overlapping traversal sequences such as ....// can collapse into ../ after sanitization, allowing generated files to be placed outside the user-selected output directory.
This vulnerability affects projects and build pipelines that use @wakaru/cli to unpack JavaScript bundles with --unpack, and that process bundle content from untrusted or semi-trusted sources.
The issue arises when the CLI derives output paths directly from module filenames contained in the bundle and relies on a single round of sanitization.
Overlapping traversal sequences such as ....// can collapse into ../ after sanitization, allowing generated files to be placed outside the user-selected output directory.
Exploit preconditions
- Attack surface: Local command-line usage of
@wakaru/cli(developer machines, CI/CD agents, automated tools). - Required access: Ability to provide or influence a JavaScript bundle that a user or automated system processes with
wakaru --unpack. - Trigger point: Execution of the unpack operation, where module filenames from the bundle are converted into filesystem paths and written to disk.
- Why exploitation is possible: The path normalization and sanitization logic is applied only once and does not account for overlapping traversal patterns that become effective after the filesystem resolves them, enabling directory traversal outside the configured output directory.
- Attack surface: Local command-line usage of
@wakaru/cli(developer machines, CI/CD agents, automated tools). - Required access: Ability to provide or influence a JavaScript bundle that a user or automated system processes with
wakaru --unpack. - Trigger point: Execution of the unpack operation, where module filenames from the bundle are converted into filesystem paths and written to disk.
- Why exploitation is possible: The path normalization and sanitization logic is applied only once and does not account for overlapping traversal patterns that become effective after the filesystem resolves them, enabling directory traversal outside the configured output directory.
Why this happens
The core issue is incomplete validation and normalization of attacker-controlled file paths before writing extracted modules to disk.
The CLI assumes that a single sanitization pass is sufficient to strip traversal sequences, but patterns like ....// are not inherently dangerous until the underlying filesystem collapses them into ../.
This aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where user-controlled path segments are used to construct file system locations without robust canonicalization and enforcement that the final result remains within an intended base directory.
The core issue is incomplete validation and normalization of attacker-controlled file paths before writing extracted modules to disk.
The CLI assumes that a single sanitization pass is sufficient to strip traversal sequences, but patterns like ....// are not inherently dangerous until the underlying filesystem collapses them into ../.
This aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, where user-controlled path segments are used to construct file system locations without robust canonicalization and enforcement that the final result remains within an intended base directory.
Potential impact
- Malicious files may be written outside the selected output directory.
- Overwrite or creation of files in sensitive project directories (e.g., configuration, scripts, or build artifacts).
- In developer environments, injected files could be picked up by tooling, package managers, or runtime loaders, potentially leading to code execution.
- In CI/CD environments, modified build outputs or scripts may compromise the integrity of the delivery pipeline.
- Malicious files may be written outside the selected output directory.
- Overwrite or creation of files in sensitive project directories (e.g., configuration, scripts, or build artifacts).
- In developer environments, injected files could be picked up by tooling, package managers, or runtime loaders, potentially leading to code execution.
- In CI/CD environments, modified build outputs or scripts may compromise the integrity of the delivery pipeline.
General mitigation guidance
Effective mitigation focuses on strict path handling and reducing trust in bundle-controlled filenames:
- Perform robust, multi-step path canonicalization and verify that the final resolved path is a descendant of the chosen output directory before writing any file.
- Reject or rewrite any module filename containing traversal indicators (
.., absolute path prefixes, drive letters, or unusual separator patterns) rather than attempting to partially sanitize them. - Use a whitelist approach for allowable path shapes (e.g., relative, no parent directory segments, no leading separators) and normalize separators consistently across platforms.
- Run tooling like
wakaruwith the least necessary filesystem privileges and avoid executing or automatically loading newly unpacked content without review. - Separate unpack output into isolated working directories that are not relied upon for direct code execution or configuration loading.
Effective mitigation focuses on strict path handling and reducing trust in bundle-controlled filenames:
- Perform robust, multi-step path canonicalization and verify that the final resolved path is a descendant of the chosen output directory before writing any file.
- Reject or rewrite any module filename containing traversal indicators (
.., absolute path prefixes, drive letters, or unusual separator patterns) rather than attempting to partially sanitize them. - Use a whitelist approach for allowable path shapes (e.g., relative, no parent directory segments, no leading separators) and normalize separators consistently across platforms.
- Run tooling like
wakaruwith the least necessary filesystem privileges and avoid executing or automatically loading newly unpacked content without review. - Separate unpack output into isolated working directories that are not relied upon for direct code execution or configuration loading.
How teams detect issues like this
Organizations can detect and monitor similar path traversal issues using several approaches:
- Static analysis and code scanning: Flag any file write operations that concatenate user- or bundle-controlled strings into paths without canonicalization and base-directory enforcement.
- Code review patterns: Pay special attention to archive or bundle extraction logic, looking for assumptions that single-pass sanitization is sufficient to prevent traversal.
- Security unit tests: Add tests that attempt to unpack bundles containing edge-case filenames (e.g.,
....//,..\\, mixed separators) and assert that outputs stay within the intended directory. - Runtime monitoring: Where feasible, monitor tooling environments for unexpected file creation or modification outside designated working directories during unpack operations.
Organizations can detect and monitor similar path traversal issues using several approaches:
- Static analysis and code scanning: Flag any file write operations that concatenate user- or bundle-controlled strings into paths without canonicalization and base-directory enforcement.
- Code review patterns: Pay special attention to archive or bundle extraction logic, looking for assumptions that single-pass sanitization is sufficient to prevent traversal.
- Security unit tests: Add tests that attempt to unpack bundles containing edge-case filenames (e.g.,
....//,..\\, mixed separators) and assert that outputs stay within the intended directory. - Runtime monitoring: Where feasible, monitor tooling environments for unexpected file creation or modification outside designated working directories during unpack operations.
