Summary
A path traversal vulnerability in the OpenAI-compatible /v1/files upload endpoint of Langchain-Chatchat 0.3.0 allows crafted filenames to escape the intended openai_files directory. An attacker who can reach the endpoint may write uploaded content to arbitrary filesystem locations permitted by the application process.
A path traversal vulnerability in the OpenAI-compatible /v1/files upload endpoint of Langchain-Chatchat 0.3.0 allows crafted filenames to escape the intended openai_files directory. An attacker who can reach the endpoint may write uploaded content to arbitrary filesystem locations permitted by the application process.
Affected context
The vulnerability occurs in deployments running Langchain-Chatchat 0.3.0 with the OpenAI-compatible file upload endpoint enabled. It becomes risky when uploaded filenames are accepted without canonicalization and are used to construct filesystem paths relative to the intended openai_files storage directory.
The vulnerability occurs in deployments running Langchain-Chatchat 0.3.0 with the OpenAI-compatible file upload endpoint enabled. It becomes risky when uploaded filenames are accepted without canonicalization and are used to construct filesystem paths relative to the intended openai_files storage directory.
Exploit preconditions
- Attack surface: The OpenAI-compatible
/v1/filesHTTP upload endpoint - Required access: Network access to the endpoint; authentication requirements depend on deployment configuration
- Trigger point: Processing and storing an uploaded file with a crafted filename
- Why exploitation is possible: Filename components are not sufficiently constrained to the designated storage directory, allowing path resolution outside the intended path
- Attack surface: The OpenAI-compatible
/v1/filesHTTP upload endpoint - Required access: Network access to the endpoint; authentication requirements depend on deployment configuration
- Trigger point: Processing and storing an uploaded file with a crafted filename
- Why exploitation is possible: Filename components are not sufficiently constrained to the designated storage directory, allowing path resolution outside the intended path
Why this happens
The underlying bug is improper limitation of a user-controlled path during file upload handling.
When an application combines an attacker-supplied filename with a trusted storage directory without canonicalizing the result and verifying that it remains within the allowed root, traversal components can redirect writes elsewhere on the filesystem.
This maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
The underlying bug is improper limitation of a user-controlled path during file upload handling.
When an application combines an attacker-supplied filename with a trusted storage directory without canonicalizing the result and verifying that it remains within the allowed root, traversal components can redirect writes elsewhere on the filesystem.
This maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Potential impact
- An attacker may overwrite or create files in locations writable by the application process
- The application may be modified or disrupted through arbitrary file placement
- Sensitive files could be damaged or replaced if process permissions allow it
- Crafted writes could contribute to code execution or broader host compromise in susceptible deployments
- Uploaded content could affect other services sharing the same filesystem
- An attacker may overwrite or create files in locations writable by the application process
- The application may be modified or disrupted through arbitrary file placement
- Sensitive files could be damaged or replaced if process permissions allow it
- Crafted writes could contribute to code execution or broader host compromise in susceptible deployments
- Uploaded content could affect other services sharing the same filesystem
General mitigation guidance
Mitigation generally focuses on treating uploaded filenames as untrusted metadata rather than filesystem paths.
Common defensive patterns include:
- Generate server-side storage names instead of using client-provided path components
- Canonicalize candidate paths and verify they remain beneath a dedicated upload directory
- Reject traversal indicators, absolute paths, separators, and unexpected filename forms
- Store uploads in isolated directories with restricted permissions and non-executable mounts where practical
- Apply least privilege to the service account and limit write access to the required storage area
- Enforce authentication, authorization, upload size, and content-type policies appropriate to the deployment
Mitigation generally focuses on treating uploaded filenames as untrusted metadata rather than filesystem paths.
Common defensive patterns include:
- Generate server-side storage names instead of using client-provided path components
- Canonicalize candidate paths and verify they remain beneath a dedicated upload directory
- Reject traversal indicators, absolute paths, separators, and unexpected filename forms
- Store uploads in isolated directories with restricted permissions and non-executable mounts where practical
- Apply least privilege to the service account and limit write access to the required storage area
- Enforce authentication, authorization, upload size, and content-type policies appropriate to the deployment
How teams detect issues like this
Organizations can look for path traversal risks through:
- Static analysis rules identifying filesystem writes that incorporate request-controlled filenames
- Code review checks for missing canonical-path containment validation
- Dynamic tests using normalized and encoded traversal variants against isolated test environments
- Web application logs showing unusual filename separators, traversal markers, or writes outside the expected directory
- Policy enforcement requiring server-generated upload names and dedicated, restricted upload roots
Automated security review tools may help identify unsafe path construction patterns during development.
Organizations can look for path traversal risks through:
- Static analysis rules identifying filesystem writes that incorporate request-controlled filenames
- Code review checks for missing canonical-path containment validation
- Dynamic tests using normalized and encoded traversal variants against isolated test environments
- Web application logs showing unusual filename separators, traversal markers, or writes outside the expected directory
- Policy enforcement requiring server-generated upload names and dedicated, restricted upload roots
Automated security review tools may help identify unsafe path construction patterns during development.
Sources
| Source | Link |
|---|---|
| gist. | gist.github.com/ |
| github. | github.com/ |
