CVE-2026-95140 in kkFileView
Summary
by MITRE • 10/06/2026
kkFileView v5.0.0 through v5.0.2 contains a directory traversal vulnerability in FileController.java. The fileUpload, createFolder and existsFile endpoints accept a "path" parameter that is concatenated into the upload base path without validation, allowing unauthenticated attackers to create arbitrary directories and write arbitrary files outside the intended fileDir root via a crafted multipart request
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in kkFileView versions 5.0.0 through 5.0.2 represents a critical directory traversal flaw located within the FileController.java component of the application architecture. This security defect stems from insufficient input validation on user-supplied data, specifically targeting three distinct endpoints: fileUpload, createFolder, and existsFile. These endpoints are designed to handle multipart requests for uploading files or managing folder structures within the document preview system. However, the implementation fails to sanitize or validate the path parameter provided by the client before concatenating it with the designated upload base directory. This lack of rigorous boundary checking allows an attacker to manipulate the file system navigation sequence using standard traversal sequences such as dot-dot-slash characters.
From a technical perspective, the core issue is a classic improper restriction of excessive administrative privileges or incorrect path canonicalization failure. When the application receives a multipart request containing a crafted path parameter, it directly appends this value to the root upload directory without verifying that the resulting absolute path remains within the intended sandboxed fileDir boundary. By injecting sequences like ../../../../etc/ into the path argument, an attacker can escape the restricted web-accessible or storage directories and write files to arbitrary locations on the underlying operating system's file hierarchy. This behavior effectively bypasses the application-level isolation mechanisms that are supposed to contain user uploads within a specific subdirectory structure.
The operational impact of this vulnerability is severe due to its unauthenticated nature, meaning no valid credentials are required to exploit it. An attacker can leverage this flaw to create arbitrary directories and write malicious files outside the intended fileDir root. This capability enables several high-severity attack vectors including remote code execution if a web shell or executable script is written into a location that is subsequently executed by the server environment, such as within an application deployment directory or system configuration path. Additionally, it allows for unauthorized data exfiltration through overwriting sensitive files like configuration files containing database credentials or API keys, and facilitates denial of service conditions by filling up critical disk partitions with large malicious payloads.
This vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, which describes flaws where software does not properly neutralize special elements within a file path that can cause the path to resolve outside of the intended directory. In terms of offensive security frameworks, this exploit maps directly to ATT&CK technique T1083: File and Directory Discovery combined with T1564: Hidden Files and Directories if used for persistence or evasion, but primarily falls under T1105: Ingress Tool Transfer when the goal is uploading malicious artifacts. The lack of authentication required further exacerbates the risk profile as it expands the attack surface to any internet-facing instance without additional access controls.
Mitigation strategies must focus on implementing strict input validation and path canonicalization checks immediately upon receipt of the multipart request data before any file system operations are attempted. Developers should normalize the provided path using standard library functions that resolve symbolic links and relative references, ensuring the final resolved absolute path starts with the expected base directory string. It is also recommended to implement allow-listing for permitted characters in filenames and paths rather than relying solely on blocklists of malicious sequences like dot-dot-slash combinations which can often be obfuscated or bypassed using encoding techniques. Upgrading to a patched version where these endpoints have been secured with proper validation logic is the primary remediation step, alongside deploying web application firewalls that can detect and block directory traversal patterns in HTTP requests as an interim defensive measure until patches are applied.