## Summary `langchain-nvidia-ai-endpoints` versions before 1.4.2 accepted local filesystem paths as image inputs for Vision Language Model (VLM) requests. If an application passed attacker-controlled image input to `ChatNVIDIA` or VLM reranking APIs, an attacker could cause files readable by the...
Full CISO analysis pending enrichment.
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| LangChain | pip | <= 1.4.1 | 1.4.2 |
Do you use LangChain? You're affected.
How severe is it?
What is the attack surface?
What should I do?
Patch available
Update LangChain to version 1.4.2
Which compliance frameworks are affected?
Compliance analysis pending. Sign in for full compliance mapping when available.
Frequently Asked Questions
What is GHSA-g28h-2cmm-rj9x?
## Summary `langchain-nvidia-ai-endpoints` versions before 1.4.2 accepted local filesystem paths as image inputs for Vision Language Model (VLM) requests. If an application passed attacker-controlled image input to `ChatNVIDIA` or VLM reranking APIs, an attacker could cause files readable by the application process to be read and included in the outbound request to the configured NVIDIA/NIM model endpoint. ## Impact Applications are affected if they use VLM image inputs with `ChatNVIDIA` or `NVIDIARerank` and allow untrusted users to control image URLs or document image metadata. An attacker who can control those inputs may be able to read local files accessible to the application process. Applications that do not use VLM image inputs, or that only pass trusted image references, are not affected. ## Patched Version Upgrade to `langchain-nvidia-ai-endpoints >= 1.4.2`. The patched version rejects raw local filesystem paths for VLM image inputs. Supported inputs are remote URLs, `data:image/...;base64,...` URIs, and supported asset/file IDs. ## Workarounds If upgrading is not immediately possible, applications should reject local filesystem paths in user-controlled VLM image inputs and only allow trusted remote URLs, data URIs, or known safe asset/file IDs. Applications should also run with least-privilege filesystem access so that the application process cannot read files it does not need.
Is GHSA-g28h-2cmm-rj9x actively exploited?
No confirmed active exploitation of GHSA-g28h-2cmm-rj9x has been reported, but organizations should still patch proactively.
How to fix GHSA-g28h-2cmm-rj9x?
Update to patched version: LangChain 1.4.2.
What is the CVSS score for GHSA-g28h-2cmm-rj9x?
GHSA-g28h-2cmm-rj9x has a CVSS v3.1 base score of 7.5 (HIGH).
What are the technical details?
Original Advisory
## Summary `langchain-nvidia-ai-endpoints` versions before 1.4.2 accepted local filesystem paths as image inputs for Vision Language Model (VLM) requests. If an application passed attacker-controlled image input to `ChatNVIDIA` or VLM reranking APIs, an attacker could cause files readable by the application process to be read and included in the outbound request to the configured NVIDIA/NIM model endpoint. ## Impact Applications are affected if they use VLM image inputs with `ChatNVIDIA` or `NVIDIARerank` and allow untrusted users to control image URLs or document image metadata. An attacker who can control those inputs may be able to read local files accessible to the application process. Applications that do not use VLM image inputs, or that only pass trusted image references, are not affected. ## Patched Version Upgrade to `langchain-nvidia-ai-endpoints >= 1.4.2`. The patched version rejects raw local filesystem paths for VLM image inputs. Supported inputs are remote URLs, `data:image/...;base64,...` URIs, and supported asset/file IDs. ## Workarounds If upgrading is not immediately possible, applications should reject local filesystem paths in user-controlled VLM image inputs and only allow trusted remote URLs, data URIs, or known safe asset/file IDs. Applications should also run with least-privilege filesystem access so that the application process cannot read files it does not need.
Weaknesses (CWE)
CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
- [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
- [Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2025-2828 10.0 LangChain RequestsToolkit: SSRF exposes cloud metadata
Same package: langchain CVE-2023-34540 9.8 LangChain: RCE via JiraAPIWrapper crafted input
Same package: langchain CVE-2023-34541 9.8 LangChain: RCE via unsafe load_prompt deserialization
Same package: langchain CVE-2023-36258 9.8 LangChain: unauthenticated RCE via code injection
Same package: langchain CVE-2023-29374 9.8 LangChain: RCE via prompt injection in LLMMathChain
Same package: langchain