Severity: High. Cross-workspace boundary violation by any authenticated workspace member.
Attacker capability: Any authenticated user with permission to update a evaluation can move it to any workspace whose UUID they can guess or enumerate (workspace UUIDs are exposed in many API responses, so enumeration is trivial). Evaluation runs (which may include captured prompts, model outputs, scoring data) can be moved cross-workspace via workspaceId overwrite, exposing the data to attacker workspace members.
Preconditions: Authenticated session with edit permission for the source evaluation. No second factor required. Workspace UUIDs are exposed via the /api/v1/workspaces listing or via any cross-referenced object's workspaceId field, so target enumeration is trivial.
Differential: PoC-verified by source inspection of the original GHSA-q4pr-4r26-c69r. Patched build (with the suggested fix below) refuses the workspaceId field; vulnerable build accepts it and persists it.
// Allowlist pattern (matches commit 840d2ae for DocumentStore):
const updatedEvaluation = new Evaluation()
if (body.<allowed_field_1> !== undefined) updatedEvaluation.<allowed_field_1> = body.<allowed_field_1>
if (body.<allowed_field_2> !== undefined) updatedEvaluation.<allowed_field_2> = body.<allowed_field_2>
// ...whitelist only the documented fields. Never copy id, workspaceId, createdDate, updatedDate from the client.
Regression tests should assert that a request body containing workspaceId, id, createdDate, or updatedDate is rejected (or at minimum: does not change those columns on the persisted row) for both create and update paths.