CVE-2026-10812
Weak Hash in GPTCache Cache Key Handler via Local Input Manipulation
Publication date: 2026-06-04
Last updated on: 2026-06-04
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| zilliztech | gptcache | to 0.1.44 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-328 | The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack). |
| CWE-327 | The product uses a broken or risky cryptographic algorithm or protocol. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in GPTCache arises from the use of the BufferedReader.peek() method, which only reads the first approximately 8192 bytes of a file to generate cache keys. This causes different files or images that share the same initial bytes to produce identical cache keys, leading to cache key collisions.
As a result, the system may return incorrect cached responses because it treats distinct files as identical based on their initial content. This flaw affects functions like get_file_bytes(), get_input_str(), and get_image_question() in the GPTCache processor.
The vulnerability can be exploited locally by manipulating the input data, specifically the image argument, to cause use of a weak hash and cache poisoning.
A fix is proposed that replaces the peek() method with a streaming SHA-256 hash of the entire file content to ensure unique cache keys and prevent collisions.
How can this vulnerability impact me? :
This vulnerability can lead to cache poisoning where incorrect or unauthorized cached responses are returned due to cache key collisions.
In shared deployments, an attacker could exploit this to access cached answers that should not be accessible or cause the system to serve wrong data.
The attack requires local access and is considered complex and difficult to exploit, but the exploit is publicly known.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the use of a weak hash in the GPTCache library's BufferedReader.peek() method, which reads only the first ~8192 bytes of a file, potentially causing cache key collisions.
Detection would involve identifying if your system is running a vulnerable version of GPTCache (up to 0.1.44) and if the functions get_file_bytes(), get_input_str(), or get_image_question() are using BufferedReader.peek() for cache key derivation.
Since the attack is local and involves file or image cache key collisions, you can check for suspicious cache key collisions or unexpected cache hits for different files with similar headers.
Specific commands are not provided in the resources, but you might consider:
- Checking the installed GPTCache version: `pip show gptcache` or inspecting your project's dependencies.
- Reviewing logs or cache entries for identical cache keys generated from different files or images.
- Using file hashing commands (e.g., `sha256sum`) on cached files to detect collisions where different files have the same cache key.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should update GPTCache to a version that includes the fix replacing BufferedReader.peek() with a streaming SHA-256 hash of the full file content.
If an updated version is not yet released, you can manually apply the fix from the pull request which:
- Replaces the use of peek() with a full content SHA-256 hash in the affected functions (get_file_bytes(), get_input_str(), get_image_question()).
- Resets the file pointer after hashing to maintain proper file handling.
- Closes file handles properly to avoid resource leaks.
Additionally, restrict local access to the system to trusted users only, as the attack requires local initiation and has high complexity.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.