Is there a public PoC exploit available for CVE-2026-10812?

Yes, a public proof-of-concept exploit is available for CVE-2026-10812. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-10812?

Yes, a patch is available for CVE-2026-10812. Update the affected software to the latest version immediately.

GPTCache CVE-2026-10812

Q: What is the CVSS score of CVE-2026-10812?

CVE-2026-10812 has a CVSS 4.0 base score of 1.1 (Low). CVSS vector: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-34272 LOW

Use of Weak Hash (CWE-328)

2026-06-04 VulDB

GHSA-xfqj-4cr9-9gr5

Information Disclosure Gptcache

1.1

CVSS 4.0 · Vendor: VulDB

Severity by source

Vendor (VulDB) PRIMARY

1.1 LOW

CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (VulDB) · only source for this CVE.

CVSS VectorVendor: VulDB

Attack Vector

Local

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

CVSS changed

Jun 04, 2026 - 15:22 NVD

3.6 (LOW) 1.1 (LOW)

Source Code Evidence Fetched

Jun 04, 2026 - 14:54 vuln.today

Analysis Generated

Jun 04, 2026 - 14:54 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

43 pypi packages depend on gptcache (14 direct, 29 indirect)

Ecosystem-wide dependent count for version 0.1.44.

DescriptionCVE.org

A vulnerability was detected in zilliztech GPTCache up to 0.1.44. Affected by this issue is the function BufferedReader.peek of the file gptcache/processor/pre.py of the component Cache Key Handler. Performing a manipulation of the argument input_data["image"] results in use of weak hash. The attack must be initiated from a local position. The attack is considered to have high complexity. The exploitation is known to be difficult. The exploit is now public and may be used. The pull request to fix this issue awaits acceptance.

AnalysisAI

Cache poisoning in zilliztech GPTCache (up to version 0.1.44) allows a local, low-privileged attacker to corrupt LLM response cache entries by exploiting weak image fingerprinting in the Cache Key Handler. The BufferedReader.peek() method in gptcache/processor/pre.py only reads the first ~8192 bytes of an image file to construct a cache key, meaning two distinct images sharing an identical header prefix generate the same cache key and collide. An attacker can submit a crafted image whose header matches a previously cached image, causing GPTCache to return a poisoned (wrong) LLM response for subsequent queries. Publicly available exploit code exists per the GitHub issue and included PoC; no active exploitation confirmed in CISA KEV at time of analysis.

Technical ContextAI

GPTCache is an open-source semantic caching layer for LLM API calls, designed to return cached responses for semantically similar queries and reduce upstream API costs. Cache keys for image-based queries are computed by three pre-embedding functions - get_input_str, get_file_bytes, and get_image_question - in gptcache/processor/pre.py. All three relied on Python's BufferedReader.peek(), which reads only up to the internal buffer size (~8192 bytes) without advancing the stream pointer. Because peek() sees only the file header rather than the full content, CWE-328 (Use of Weak Hash) applies: the resulting cache key is a structurally incomplete digest, not a collision-resistant fingerprint. Affected product identified by CPE cpe:2.3:a:zilliztech:gptcache:*:*:*:*:*:*:*:* covering all versions through 0.1.44. The fix in PR #678 introduces a _hash_file() helper that iterates the full file content in 64KB chunks, computes SHA-256, and resets the file pointer - a proper collision-resistant replacement.

RemediationAI

The upstream fix is available as pull request #678 (https://github.com/zilliztech/GPTCache/pull/678), which replaces all peek()-based image fingerprinting with a full-file SHA-256 hash via the new _hash_file() helper. However, this PR awaits acceptance and has not been released in a tagged version - an upstream fix available (PR/commit); released patched version not independently confirmed. Users should monitor the GPTCache GitHub repository (https://github.com/zilliztech/GPTCache/) for a release incorporating PR #678 and upgrade immediately upon availability. As an interim workaround for deployments using image-based queries, operators can manually patch gptcache/processor/pre.py by applying the PR #678 diff locally, which has no functional side effects beyond increased I/O per image cache lookup due to full-file hashing. Deployments that do not use image inputs (get_input_str with image fields, get_file_bytes, or get_image_question) are not exposed to this specific attack path and can defer patching until the next scheduled upgrade cycle. Restricting write access to the GPTCache input interface to trusted users reduces exploitation opportunity but does not eliminate the vulnerability.