CVE-2024-2057 is a medium severity flaw in the TFIDFRetriever of LangChain Community, scored CVSS 6.3. The record describes it as server-side request forgery in the load_local function of version 0.0.26. The record says upgrading to 0.0.27 addresses it, so update langchain-community and avoid loading retriever files from sources you do not trust.
What's affected
The record names langchain_community version 0.0.26 and says that upgrading to 0.0.27 addresses the issue. The affected function is load_local in libs/community/langchain_community/retrievers/tfidf.py, part of the TFIDFRetriever component. NVD classifies the weakness as CWE-918, server-side request forgery, with a CVSS 3.1 score of 6.3 (Medium) and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L. It was published on 2024-03-01 under the VulDB identifier VDB-255372.
There is a wrinkle in how the issue is described. The NVD text calls it server-side request forgery. The maintainers' fix, a pull request titled "Patch tdidf retriever (CVE-2024-2057)" merged on 6 March 2024, describes it differently: it says the issue affects users who use the TFIDFRetriever and try to deserialize it from an untrusted source containing a malicious payload. Those are two framings of the same bug report, and we cannot tell from the sources which one is the more complete picture. The practical advice is the same either way.
The record also says the vulnerable code runs when a retriever is loaded from disk, and that an exploit was disclosed publicly. We did not retrieve the VulDB entry, so we cannot say more about exploit details, and we will not repeat any.
How to check if you're exposed
Check which version of the package you have in each environment that runs LangChain code. The distribution name on PyPI uses a hyphen:
pip show langchain-community
pip list | grep -i langchain
If you use a lock file, search it for langchain-community. Any resolved version of 0.0.26 is the version named in the record. Versions before 0.0.26 are not described in the record, so do not treat them as safe without checking; the fix landed in 0.0.27, so upgrading past it is the clean answer.
Then check how your code uses the retriever. Search your repositories for the class name and for load_local:
grep -rn "TFIDFRetriever" .
grep -rn "load_local" .
The maintainers' pull request frames the risk as loading a saved retriever from an untrusted source. If every file you load was produced by your own pipeline and stored somewhere only you control, your exposure is lower. If users can upload or point to retriever files, it is higher.
For a broader answer across many repositories, the free in-browser dependency scan at gold.safeguard.sh/scan reads manifests and lock files and reports known vulnerable versions. Reachability analysis helps with the second question, whether your code actually calls the affected function.
What to do now
- Upgrade langchain-community to 0.0.27 or later, then rebuild and redeploy images that pin the old version.
- Search code for TFIDFRetriever and load_local to see where saved retrievers are loaded.
- Stop loading retriever files from untrusted or user supplied locations. Treat serialized files as code, not data.
- If you must accept saved indexes from others, validate their origin and keep the loading process in a restricted sandbox with limited network access.
- Pin your langchain packages in a lock file so a transitive update does not quietly bring back an old version.
- Re-run your dependency scan after the upgrade to confirm the finding is cleared.
Why it matters
This bug sits where machine learning tooling meets old problems. Loading a saved object from disk can run code or make network requests as a side effect, because the file format carries more than plain data. Libraries that offer a convenient load function for a saved index are quietly asking you to trust the file. Once a user can influence which file is loaded, that trust is misplaced.
The NVD class, CWE-918, describes a server being tricked into sending requests it should not. The maintainers' own description points at untrusted deserialization. Both lead to the same control: do not load files you do not control. CVE-2024-2057 is not on the CISA Known Exploited Vulnerabilities list, and none of the sources we read report exploitation in the wild, although the record says a public exploit exists.
Try it yourself
This demo shows how an exploitability check separates a flagged library from code your application actually calls.
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2024-2057 fixed?
The record says upgrading to langchain_community 0.0.27 addresses it, and the maintainers merged a patch on 6 March 2024.
Do I need to worry if I never load a saved retriever?
The described problem is in loading a TFIDFRetriever from disk. If your code never does that, the exposure is much smaller, but upgrading is still cheap.
Sources
- LangChain pull request 18695, Patch tdidf retriever
- Gold entry for CVE-2024-2057
- VulDB entry VDB-255372 and the researcher repository are referenced by the record but were not retrieved.
Last reviewed: 19 October 2026.
