Description

kkFileView is a universal file online preview project based on Spring Boot. Prior to 5.0.1, the unauthenticated POST /listFiles endpoint in server/src/main/java/cn/keking/web/controller/FileController.java passes the user-controlled path parameter from FileController#getFiles to Files.newDirectoryStream without confinement to the demo directory, allowing directory enumeration outside the intended root. This issue is fixed in version 5.0.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-11T20:18:49.547Z",
  "pubdate": "2026-08-11T20:18:49.547Z",
  "executiveSummary": "An arbitrary directory enumeration vulnerability exists in the kkFileView universal file online preview project prior to version 5.0.1.\nThe vulnerability allows unauthenticated remote attackers to enumerate directories outside the intended root directory on the underlying host system.\nThe flaw resides in the unauthenticated POST /listFiles endpoint, specifically within server/src/main/java/cn/keking/web/controller/FileController.java and the FileController#getFiles method.\nBy supplying a malicious or traversing user-controlled path parameter, an attacker can bypass intended logical boundaries due to the insecure invocation of Files.newDirectoryStream without proper path confinement.\nSuccessful exploitation compromises the confidentiality of the server's filesystem structure, allowing unauthorized reconnaissance.\nNo authentication or special privileges are required to exploit this endpoint over network exposure, significantly increasing the risk profile for exposed instances.",
  "technicalDetails": "The vulnerability stems from insufficient input validation and path sanitization within the kkFileView application prior to version 5.0.1.\nThe vulnerable component is identified as the unauthenticated POST /listFiles endpoint handled by the FileController#getFiles function located in server/src/main/java/cn/keking/web/controller/FileController.java.\nThe root cause of the flaw is the direct processing of a user-controlled path parameter passed to the Java NIO Files.newDirectoryStream method without enforcing strict confinement or canonical path checks against the designated demo directory.\nNetwork exposure is present externally via the HTTP POST method on the /listFiles endpoint, requiring zero authentication and zero pre-existing privileges.\nDuring exploitation, an attacker crafts an HTTP POST request targeting the /listFiles endpoint, injecting a custom or directory-traversal payload into the path parameter.\nUpon receiving the request, the FileController#getFiles method retrieves the unsanitized parameter and forwards it directly to the filesystem iteration logic via Files.newDirectoryStream.\nBecause the application fails to restrict the boundary of the lookup directory, the Java runtime executes the directory stream operation on the arbitrary path supplied by the attacker.\nThe application subsequently returns the listing of directory contents to the unauthenticated client.\nPost-exploitation impact includes severe reconnaissance capabilities, enabling attackers to map sensitive internal directory structures, locate configuration files, and gather intelligence for subsequent attack vectors."
}