Summary
The REST endpoint POST /api/automations/confirmations/:id/respond validates the request body via Zod in src/server/routes/automations.ts. The corresponding WebSocket handler in src/server/routes/ws/commands/confirmation-response.ts forwards message.data to handleConfirmationResponse and bus.publish with no validation.
A malformed client payload (or one from a compromised client process such as a browser extension or embedded webview) can therefore inject content into the model prompt via formatConfirmationAttachmentBlock in src/server/processor/confirmation/confirmation.service.ts, which formats the attachment list into an <attached_files> block fed back to the LLM.
Impact
Prompt-injection foothold, not a direct file-read vulnerability — the agent still has to call read_file, which is gated by the sensitive-path check covered by tests/server/security/tool-protection.test.ts. But:
attachments may be an arbitrarily large array, becoming a large prompt suffixpath may be a non-string (number, object, prototype-shaped value)- The asymmetry (REST validated, WS not) is hard to spot from the call sites and easy to regress
Proposed fix
Extract the response schema into a shared module under src/server/processor/confirmation/ and consume it from both transports. Cap attachments-per-response, path length, and name length.
I have a fix ready locally and will open a PR shortly.
Summary
The REST endpoint
POST /api/automations/confirmations/:id/respondvalidates the request body via Zod insrc/server/routes/automations.ts. The corresponding WebSocket handler insrc/server/routes/ws/commands/confirmation-response.tsforwardsmessage.datatohandleConfirmationResponseandbus.publishwith no validation.A malformed client payload (or one from a compromised client process such as a browser extension or embedded webview) can therefore inject content into the model prompt via
formatConfirmationAttachmentBlockinsrc/server/processor/confirmation/confirmation.service.ts, which formats the attachment list into an<attached_files>block fed back to the LLM.Impact
Prompt-injection foothold, not a direct file-read vulnerability — the agent still has to call
read_file, which is gated by the sensitive-path check covered bytests/server/security/tool-protection.test.ts. But:attachmentsmay be an arbitrarily large array, becoming a large prompt suffixpathmay be a non-string (number, object, prototype-shaped value)Proposed fix
Extract the response schema into a shared module under
src/server/processor/confirmation/and consume it from both transports. Cap attachments-per-response, path length, and name length.I have a fix ready locally and will open a PR shortly.