Submit #838873: VoltAgent 2.1.17 Improper Authorization

A vulnerability was found in VoltAgent @voltagent/server-core 2.1.17 and classified as high severity. Affected is the memory REST API implemented in the @voltagent/server-core package and exposed through server adapters such as @voltagent/server-hono, @voltagent/server-elysia, and @voltagent/serverless-hono.

The memory handlers retrieve and mutate conversation objects by caller-supplied conversationId without enforcing object-level authorization against the authenticated principal. The Hono and Elysia authentication middleware can authenticate a request, but the memory route handlers pass query/body fields to server-core without passing the authenticated user to the memory handlers for ownership checks. In particular, handleGetMemoryConversation fetches resolved.memory.getConversation(conversationId) and returns it directly; handleListMemoryConversationMessages falls back to conversation.userId when query.userId is omitted; handleGetMemoryWorkingMemory fetches conversation-scoped working memory by conversationId; and handleDeleteMemoryConversation deletes by conversationId only.

It is possible to launch the attack remotely against applications that expose the VoltAgent memory REST API. Authentication required: yes, when the application enables the supported auth middleware. User interaction required: no.

Technical Details
- Confirmed affected version: @voltagent/server-core 2.1.17
- Confirmed repository tag/commit: @voltagent/[email protected] / 5be7626632cc7fb8798ec0a06774af6560184e52
- Confirmed exposing adapter versions in the same repository snapshot: @voltagent/server-hono 2.0.13, @voltagent/server-elysia 2.0.8, @voltagent/serverless-hono 2.0.11
- Affected file/function: packages/server-core/src/handlers/memory.handlers.ts / handleGetMemoryConversation, handleListMemoryConversationMessages, handleGetMemoryWorkingMemory, handleDeleteMemoryConversation
- Affected routes: GET /api/memory/conversations/:conversationId, GET /api/memory/conversations/:conversationId/messages, GET /api/memory/conversations/:conversationId/working-memory, DELETE /api/memory/conversations/:conversationId
- Vulnerable parameter: conversationId
- Attack vector: Network
- Privileges required: Low
- Trigger condition: An authenticated attacker knows or guesses another user's conversationId in an application exposing the memory REST API.

Impact
- Confidentiality: High
- Integrity: High
- Availability: High

CVSS v3.1
Score: 8.8 (High)
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Timeline
- Discovered: 2026-05-14
- Vendor notified: 2026-05-27
- Patch released: [unknown]
- Public disclosure: [unknown]

Countermeasure
Pass authenticated user context from server middleware into all memory API handlers and enforce object-level authorization before every read, update, clone, search, or delete operation. Do not trust query/body userId as an authorization source. Conversation lookup should verify ownership or an explicit policy decision using authenticated user_id, resource_id, agent_id, and any tenant context before returning or mutating memory objects.

• Source: ⚠️ https://github.com/VoltAgent/voltagent/issues/1315
• User: Dem000000 (UID 98564)
• Submission: 05/27/2026 14:58 (1 month ago)
• Moderation: 06/28/2026 08:29 (1 month later)
• Status: Accepted
• VulDB entry: 374519 [VoltAgent up to 2.1.17 Memory REST API memory.handlers.ts handleGetMemoryConversation conversationId improper authorization]
• Points: 20