Summary
YiShaAdmin contains an unauthenticated path traversal vulnerability in the File/DownloadFile endpoint, where the filePath parameter can reference locations outside the intended download directory. An attacker may read arbitrary files and, when deletion is enabled, remove files accessible to the application process.
YiShaAdmin contains an unauthenticated path traversal vulnerability in the File/DownloadFile endpoint, where the filePath parameter can reference locations outside the intended download directory. An attacker may read arbitrary files and, when deletion is enabled, remove files accessible to the application process.
Affected context
The issue occurs in YiShaAdmin deployments using the /admin/File/DownloadFile endpoint when user-controlled file paths are resolved without sufficient canonicalization and boundary checks. Risk is higher when the endpoint is reachable without authentication and the application process has access to sensitive system or application files.
The issue occurs in YiShaAdmin deployments using the /admin/File/DownloadFile endpoint when user-controlled file paths are resolved without sufficient canonicalization and boundary checks. Risk is higher when the endpoint is reachable without authentication and the application process has access to sensitive system or application files.
Exploit preconditions
- Attack surface: The
/admin/File/DownloadFileHTTP endpoint - Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Processing the
filePathparameter during file download handling - Additional condition: The application must be able to access the targeted file
- Deletion condition: File removal requires the deletion behavior to be enabled and the process to have delete permissions
- Why exploitation is possible: User-supplied paths are accepted without reliably restricting resolution to the intended storage directory
- Attack surface: The
/admin/File/DownloadFileHTTP endpoint - Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Processing the
filePathparameter during file download handling - Additional condition: The application must be able to access the targeted file
- Deletion condition: File removal requires the deletion behavior to be enabled and the process to have delete permissions
- Why exploitation is possible: User-supplied paths are accepted without reliably restricting resolution to the intended storage directory
Why this happens
The vulnerability results from improper limitation of a file path derived from HTTP input. When traversal sequences are accepted and the resulting path is not canonicalized and checked against an approved directory, the application may resolve references outside its intended file boundary.
This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The insecure pattern combines attacker-controlled path input with file read or deletion operations without enforcing a trusted storage root.
The vulnerability results from improper limitation of a file path derived from HTTP input. When traversal sequences are accepted and the resulting path is not canonicalized and checked against an approved directory, the application may resolve references outside its intended file boundary.
This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'). The insecure pattern combines attacker-controlled path input with file read or deletion operations without enforcing a trusted storage root.
Potential impact
- An unauthenticated attacker may read sensitive system, configuration, or application files
- The application may disclose credentials, tokens, or other secrets stored in accessible files
- An attacker could remove files required for application availability or operation
- Compromised files could support follow-on attacks or broader application compromise
- Exposure of sensitive data could create privacy, compliance, or operational consequences
- An unauthenticated attacker may read sensitive system, configuration, or application files
- The application may disclose credentials, tokens, or other secrets stored in accessible files
- An attacker could remove files required for application availability or operation
- Compromised files could support follow-on attacks or broader application compromise
- Exposure of sensitive data could create privacy, compliance, or operational consequences
General mitigation guidance
Mitigation generally focuses on treating file path parameters as untrusted references rather than filesystem locations.
Common defensive patterns include:
- Resolve requested paths against a fixed, trusted storage directory and verify that the canonical result remains within that directory
- Prefer opaque file identifiers or server-managed filenames instead of accepting filesystem paths
- Reject traversal markers, absolute paths, symbolic-link escapes, and unexpected path formats as defense-in-depth
- Separate download and deletion capabilities, requiring explicit authorization for destructive operations
- Apply least-privilege filesystem permissions to the application process and isolate downloadable content
- Disable unauthenticated access where it is not required and enforce authorization at the endpoint
- Use read-only storage or controlled deletion services where possible
Mitigation generally focuses on treating file path parameters as untrusted references rather than filesystem locations.
Common defensive patterns include:
- Resolve requested paths against a fixed, trusted storage directory and verify that the canonical result remains within that directory
- Prefer opaque file identifiers or server-managed filenames instead of accepting filesystem paths
- Reject traversal markers, absolute paths, symbolic-link escapes, and unexpected path formats as defense-in-depth
- Separate download and deletion capabilities, requiring explicit authorization for destructive operations
- Apply least-privilege filesystem permissions to the application process and isolate downloadable content
- Disable unauthenticated access where it is not required and enforce authorization at the endpoint
- Use read-only storage or controlled deletion services where possible
How teams detect issues like this
Organizations can detect related weaknesses through:
- Static analysis rules that flag filesystem operations using request parameters
- Code review checks for path joining without canonicalization and directory-boundary validation
- Tests covering encoded, normalized, absolute, traversal, and symbolic-link path variants
- Runtime monitoring for unusual file access or deletion requests involving system and configuration directories
- Web application firewall or gateway policies that identify suspicious path patterns as a supplementary control
- Automated security review tools that correlate file operations with unauthenticated routes
Organizations can detect related weaknesses through:
- Static analysis rules that flag filesystem operations using request parameters
- Code review checks for path joining without canonicalization and directory-boundary validation
- Tests covering encoded, normalized, absolute, traversal, and symbolic-link path variants
- Runtime monitoring for unusual file access or deletion requests involving system and configuration directories
- Web application firewall or gateway policies that identify suspicious path patterns as a supplementary control
- Automated security review tools that correlate file operations with unauthenticated routes
