CVE-2026-88394 in WookTeam
Summary
by MITRE • 10/05/2026
WookTeam v1.6.6 and before is vulnerable to a Directory Traversal. The project task export endpoint /api/project/task/export downloads an arbitrary file from the server when the data parameter is supplied with a crafted JSON payload. The file value inside the JSON is concatenated directly into storage_path($file) without any path normalization or directory boundary check, so directory traversal (../) escapes the storage/ directory and response()->download() streams any file readable by the web server process.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
WookTeam version 1.6.6 and earlier versions contain a critical Directory Traversal vulnerability within its project task export functionality. This security flaw resides in the API endpoint designated for exporting tasks, specifically located at /api/project/task/export. The vulnerability arises from improper handling of user-supplied input during file retrieval operations. When an authenticated or unauthenticated attacker interacts with this endpoint by supplying a crafted JSON payload via the data parameter, they can manipulate the internal logic to access files outside of the intended directory scope. This represents a classic instance of insecure direct object reference combined with path traversal techniques, allowing for unauthorized access to sensitive server-side resources that should remain isolated from web-accessible contexts.
The technical root cause lies in how the application processes the file value provided within the JSON payload. The backend code concatenates this user-controlled input directly into a storage_path function call without performing any necessary sanitization or normalization steps. Specifically, there is an absence of path canonicalization to resolve relative directory sequences such as ../ and an lack of boundary checks to ensure the resulting path remains within the designated storage/ directory. Because the application fails to validate that the resolved file path starts with the expected base directory prefix, it allows attackers to traverse up the filesystem hierarchy using standard Unix-style traversal characters. This logic error effectively bypasses any implicit or explicit security controls intended to restrict access to specific subdirectories.
The operational impact of this vulnerability is severe, as it enables arbitrary file read capabilities on the underlying server infrastructure. By exploiting this flaw, an attacker can stream and download any file that the web server process has permission to read. This includes sensitive configuration files containing database credentials or API keys, source code repositories with proprietary logic, user data dumps, system logs revealing internal network topology, and potentially other critical application artifacts. The use of response()->download() ensures that these files are served directly to the attacker in a format suitable for immediate retrieval, facilitating further exploitation phases such as credential theft, intellectual property exfiltration, or deeper reconnaissance against the target environment.
From an industry standards perspective, this vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within file paths that can cause unintended directory traversal. Additionally, in terms of tactical classification under MITRE ATT&CK, this behavior corresponds to T1083: File and Directory Discovery, as the attacker is actively enumerating and accessing files on the system to gather intelligence for subsequent attacks. The exploitation method also reflects aspects of CWE-20: Improper Input Validation, where the application fails to adequately sanitize or validate user input before processing it in a security-critical context.
To mitigate this vulnerability, immediate remediation efforts should focus on implementing robust path validation mechanisms within the export endpoint logic. Developers must ensure that all file paths are canonicalized and strictly validated against an allowlist of permitted directories before any filesystem operations occur. It is essential to resolve symbolic links and normalize relative path components like ../ to their absolute equivalents, then verify that the final resolved path begins with the expected base storage directory prefix. If the calculated path falls outside this boundary, the request should be rejected immediately. Furthermore, applying the principle of least privilege by restricting the web server process permissions can limit the scope of files accessible even if traversal occurs. Regular security audits and static code analysis tools configured to detect such input validation failures are recommended to prevent similar issues in future development cycles.