| Title | MyScale MyScaleDB 1.8.0 source tree at commit 20a16d32; likely affected where the same vector-index mutation/cache code is present CWE-345 Insufficient Verification of Data Authenticity |
|---|
| Description | A vulnerability was found in MyScaleDB 1.8.0 and classified as medium severity.
Affected is the vector index mutation and cache handling path. The issue occurs
when ALTER TABLE ... UPDATE changes a column that has a vector index.
Technical Details
- Affected files/functions:
- src/VectorIndex/Common/SegmentId.h: SegmentId::getCacheKey
- src/Storages/MergeTree/MutateTask.cpp: getVectorIndicesToRebuild and mutation finalization
- src/VectorIndex/Common/VIWithDataPart.cpp: inheritVectorIndexStatus
- src/Interpreters/MutationsInterpreter.cpp: validateUpdateColumns
- Vulnerable parameter/data: vector-indexed column updated through ALTER UPDATE
- Attack vector: Network, through authenticated SQL access
- Privileges required: Low, requiring permissions to update table data and execute vector search on the target table
- User interaction required: No
- Trigger condition: a table has a built vector index, a user mutates the indexed vector column, and later vector-search queries use the inherited or cached index state
Root Cause
The vector index cache key drops the mutation version from part names. A source
part such as all_1_1_0 and a mutated part such as all_1_1_0_5 therefore share
the same cache part component. The mutation path can hardlink vector index files
from the old part into the new mutated part and then inherit the old vector
index status. However, getVectorIndicesToRebuild only marks MATERIALIZE_COLUMN
commands for vector index rebuild and does not mark ordinary UPDATE assignments
to the indexed vector column. UPDATE validation also does not reject ordinary
columns that are vector-indexed.
Impact
- Confidentiality: Low
- Integrity: Low
- Availability: None
The practical impact is stale or incorrect nearest-neighbor results after table
data has changed. In RAG, recommendation, retrieval, or access-decision
pipelines backed by vector search, this can cause retrieval of documents or
rows based on obsolete embeddings. It may misroute results across updated
semantic states, return records that should no longer match, or hide records
that should match after the update.
CVSS v3.1
Score: 4.3 (Medium)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Timeline
- Discovered: 2026-05-27
- Vendor notified: before or on 2026-05-27; exact date unknown
- Patch released: [unknown]
- Public disclosure: [unknown]
Countermeasure
Invalidate or rebuild vector indices whenever ALTER UPDATE modifies an indexed
vector column. Do not hardlink old .vidx files into the mutated part when the
indexed column changed. Include the mutation version or an index-content version
in the vector index cache identity, or explicitly remove the affected
VICacheManager entry after mutation. Add regression coverage comparing
vector-index search with brute-force search after ALTER UPDATE on the vector
column. |
|---|
| Source | ⚠️ https://github.com/myscale/MyScaleDB/issues/54 |
|---|
| User | Dem000000 (UID 98564) |
|---|
| Submission | 05/27/2026 15:15 (1 month ago) |
|---|
| Moderation | 06/28/2026 08:33 (1 month later) |
|---|
| Status | Accepted |
|---|
| VulDB entry | 374521 [MyScale MyScaleDB up to 1.8.0 SegmentId.h SegmentId::getCacheKey data authenticity] |
|---|
| Points | 20 |
|---|