CVE-2026-88592: SSRF
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
kkFileViewto a version that resolves this vulnerability.Fixed in 4.2.0
Event History
Frequently Asked Questions
What does an attacker need to supply to bypass the host whitelist?
The request must include both urlPath and url parameters. url must contain a whitelisted decoy address so it passes TrustHostFilter validation, while urlPath contains the actual target that the controller fetches.
Which deployments should be treated as affected?
kkFileView versions 4.2.0 and later are affected. The relevant functionality is the /getCorsFile cross-origin file proxy endpoint.
Does the trust.host whitelist stop this attack?
Not when both parameters are supplied as described. The filter validates a parameter according to its own priority order, but the controller fetches only urlPath, allowing the fetched target to differ from the validated host.
What is the impact of a successful request?
The server makes the request to the target specified in urlPath, and the target response body is returned to the attacker.