CVE-2026-88592 in kkFileView
Summary
by MITRE • 09/16/2026
kkFileView >= 4.2.0 is vulnerable to Server-Side Request Forgery (SSRF). The cross-origin file proxy endpoint /getCorsFile is protected by TrustHostFilter against the trust.host whitelist. However, the URL parameter validated by the filter is not the same parameter the controller actually fetches: the filter validates the first non-empty parameter in a fixed priority order, while the controller only reads and fetches urlPath. By supplying both urlPath=<real target> and url=<whitelisted decoy address> in the same request, the decoy passes validation while the unvalidated real target is fetched server-side — and the response body is echoed back to the attacker.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in kkFileView versions 4.2.0 and above represents a critical Server-Side Request Forgery (SSRF) flaw rooted in an inconsistent implementation of input validation logic within the application's request handling pipeline. This specific weakness is categorized under CWE-918, which describes flaws where server-side requests are made to unintended destinations due to insufficient verification of user-supplied data. The core issue lies in the discrepancy between the security filter and the business logic controller responsible for processing file retrieval requests. Specifically, the endpoint /getCorsFile utilizes a TrustHostFilter designed to enforce a whitelist of trusted hosts defined by the trust.host configuration parameter. This mechanism is intended to prevent the application from making HTTP requests to arbitrary internal or external resources that could lead to data exfiltration or network reconnaissance against protected infrastructure.
The technical flaw arises from a mismatch in parameter binding between the security filter and the controller method. The TrustHostFilter operates by inspecting incoming request parameters using a fixed priority order, selecting the first non-empty parameter it encounters for validation against the whitelist of trusted hosts. In contrast, the underlying controller logic does not utilize this same prioritized selection mechanism; instead, it explicitly reads and processes only the urlPath parameter to determine the target resource location. This architectural inconsistency creates an exploitable bypass condition where an attacker can manipulate which parameter is validated versus which one is executed. By crafting a request that includes both a valid whitelisted URL in the url parameter and a malicious internal or external IP address in the urlPath parameter, the filter validates the benign decoy value while the controller proceeds to fetch the unvalidated target from server-side memory.
The operational impact of this vulnerability is severe, as it allows an authenticated attacker to leverage the application's server resources to initiate requests to arbitrary destinations within the local network or on the public internet. Since kkFileView often runs with elevated privileges relative to other services in a document management ecosystem, successful exploitation can facilitate access to internal APIs, cloud metadata endpoints such as AWS EC2 instance metadata service 169.254.169.254, or sensitive backend microservices that are not exposed directly to the internet. The vulnerability is further exacerbated by the fact that the response body from the forged request is echoed back to the attacker's client. This reflective behavior transforms a simple SSRF into an effective data exfiltration vector, enabling the retrieval of confidential documents, configuration files, or authentication tokens stored on internal servers.
From a threat intelligence perspective, this exploitation technique aligns with MITRE ATT&CK tactic T1598, specifically sub-technique T1598.002 regarding Phishing for Intranet Credentials, as SSRF is frequently used to pivot into trusted networks and harvest credentials or sensitive data from internal services that trust the application server's identity. The attack pattern also reflects common misconfigurations found in web frameworks where security controls are applied at a different layer of abstraction than the business logic execution path. To mitigate this risk, developers must ensure strict consistency between validation filters and controller parameter binding mechanisms. It is recommended to implement allowlisting directly within the service method that performs the HTTP request rather than relying solely on filter-level checks that may be bypassed through parameter manipulation. Additionally, enforcing a single source of truth for URL parsing logic and validating all user-supplied inputs against a strict whitelist before any network activity occurs will prevent such discrepancies from being exploited.