GHSA-4r4w-2wgp-w7cj Open WebUI Prompt history IDOR: unbound history_id allows cross-prompt read and deletion
SummaryOpen WebUI's prompt version-history endpoints authorize the `prompt_id` in the URL but then act on caller-supplied history IDs without verifying that the history row belongs to that prompt (`history_entry.prompt_id == prompt.id`). Three operations are affected:`GET /api/v1/prompts/id/{prompt_id}/history/diff` — returns another prompt's history snapshots (read).`POST /api/v1/prompts/id/{prompt_id}/update/version` — restores another prompt's snapshot into the caller's prompt, exposing its content (read).`DELETE /api/v1/prompts/id/{prompt_id}/history/{history_id}` — deletes another prompt's history entry (delete).An authenticated user with access to any prompt they control, plus a victim `prompt_history.id`, can read or delete another user's private prompt history. The single-entry read endpoint (`GET .../history/{history_id}`) already enforces the binding; these three did not.ImpactSecurity boundary crossed: prompt confidentiality and integrity.Prompt history snapshots can contain private prompt text, internal instructions, and sensitive variables. With a known victim `prompt_history.id`, an attacker can read another user's snapshot (via the diff endpoint or by restoring it into their own prompt) and delete another user's history entry. The active prompt row is not destroyed; the delete impact is against version history. Exploitation requires knowing or obtaining victim history UUIDs, so severity depends on adjacent ID exposure.Root CauseThe route checks read access only for `prompt_id`:But the authorized prompt ID is not passed into the diff sink:`compute_diff()` fetches both history entries globally by ID and returns their full snapshots:There is no check that `from_entry.prompt_id == prompt_id` or `to_entry.prompt_id == prompt_id`.The same missing binding affects two further endpoints. `POST .../update/version` restores a snapshot fetched globally by `version_id`:`DELETE .../history/{history_id}` deletes an entry fetched globally by `history_id`:Neither checks `entry.prompt_id == prompt.id`. The single-entry read endpoint (`GET .../history/{history_id}`) does (`history_entry.prompt_id != prompt.id → 404`); these three endpoints were missing it.PoCThe PoC executes the real route function and the real `PromptHistories.compute_diff()` implementation with fake model/DB adapters. It authorizes the attacker against `attacker-prompt`, then supplies two victim history IDs. The route returns the victim prompt snapshots.Result:Exploit SketchRead via the diff endpoint:Attacker has read access to `ATTACKER_PROMPT_ID`.Attacker knows two history IDs for a victim prompt: `VICTIM_FROM_HISTORY_ID` and `VICTIM_TO_HISTORY_ID`.Attacker requests:The server authorizes `ATTACKER_PROMPT_ID`, then returns snapshots for the victim history IDs.Read via restore (`update/version`): the attacker `POST`s `{"version_id": "VICTIM_HISTORY_ID"}` to their own prompt's `update/version`, then `GET`s their prompt; it now holds the victim snapshot's name/content/data/meta/tags.Delete: the attacker sends `DELETE /api/v1/prompts/id/ATTACKER_PROMPT_ID/history/VICTIM_HISTORY_ID`; the victim history entry is removed.Recommended FixBind every prompt-history operation to the authorized prompt before acting on a history ID, mirroring the single-entry read endpoint:`compute_diff()` should accept `prompt_id` and query both entries with `PromptHistory.prompt_id == prompt_id` alongside the id filter.`delete_history_entry()` should accept `prompt_id` and filter `filter_by(id=history_id, prompt_id=prompt_id)`.`update_prompt_version()` should reject `history_entry.prompt_id != prompt_id` before restoring.Return 404/403 on mismatch.ConsolidationPer our Report Handling policy this consolidates independent reports of the same prompt-history authorization flaw (one missing `history_entry.prompt_id == prompt.id` binding) reached through different endpoints:Diff-endpoint read and history deletion: @0xEr3n (earliest filings).`update/version` restore-read: distinct path demonstrated by @5yu4n.One CVE for the consolidated advisory.
CVSS v3.1 score: 6.4