Both session factories run with expire_on_commit=False, so ORM objects keep their attribute values after commit. Every session.refresh issued right after a commit therefore re-SELECTed a row whose values the session already held, including full chat JSON blobs and user settings, purely to overwrite identical data. Fifty such calls existed across the model layer, covering nearly every write path in the app (chat inserts, title updates, pin/archive toggles, user role and settings updates, tool, prompt, function, model, file, tag, feedback, memory, automation and grant writes).
All fifty are removed. The only refreshes with an actual job were the two update-then-reload paths in tools and skills, where a Core UPDATE statement bypasses the identity map; those now use session.get(..., populate_existing=True), which guarantees a fresh row in one SELECT whether or not the row was already present in the session (the previous code issued get plus refresh, two SELECTs, on the default configuration).
Benchmark (real SQLite DB, per write):
| write path | before | after |
| --- | --- | --- |
| chat title update, ~600 KB chat blob | 2.08 ms | 1.24 ms |
| user role update, small row | 1.21 ms | 0.68 ms |
On Postgres each removed refresh is additionally a network round trip. The chat-blob case also skips re-parsing the entire JSON document per write.
Functionally verified against a fresh database: user insert, role and settings updates, chat insert (including the server-default meta column, which is always provided client-side), title update and pin toggle, tool insert and the Core-update reload path, tag insert and the prompt insert flow that pins version_id after history creation all return correct values and persist correctly.
* fix: prevent mass-assignment user_id spoofing in POST /api/v1/evaluations/feedback
Two independent gaps in backend/open_webui/models/feedbacks.py let an
authenticated caller forge the `user_id` (and `id`, `version`) on a new
feedback record submitted to POST /api/v1/evaluations/feedback:
1. `FeedbackForm` declared `model_config = ConfigDict(extra='allow')`,
so Pydantic preserved any extra fields supplied in the request body —
including `user_id`, `id`, `version`. The form is the public input
boundary for the endpoint and should not accept unknown fields.
2. In `insert_new_feedback`, the dict literal placed
`**form_data.model_dump()` AFTER `'id': id`, `'user_id': user_id`,
`'version': 0`. Python dict-literal duplicate-key resolution is
last-wins, so any of those fields present in `form_data` overwrote
the server-derived values.
Combined effect: a regular user could POST a feedback record with an
arbitrary `user_id`, attributing the rating to any other user. The Elo
leaderboard at backend/open_webui/routers/evaluations.py computes model
rankings from these records, and the admin export
(GET /api/v1/evaluations/feedbacks/export) and admin list
(GET /api/v1/evaluations/feedbacks/all) display the spoofed attribution.
Two fixes, defense-in-depth:
- FeedbackForm: switch `extra='allow'` to `extra='ignore'` so Pydantic
drops unknown fields at parse time. Sub-models (RatingData / MetaData /
SnapshotData) intentionally keep `extra='allow'` because their contents
are deliberately schema-flexible — the spoofing surface was the form,
not the sub-payloads.
- insert_new_feedback: spread `form_data.model_dump()` first, then
overlay server-controlled fields (`id`, `user_id`, `version`,
`created_at`, `updated_at`) so the explicit keys win on duplicate-key
resolution regardless of what reaches the function. Matches the secure
pattern already used in backend/open_webui/models/functions.py:120.
Reported by yantongggg in GHSA-rjmp-vjf2-qf4g. Same root-cause class as
the prior published GHSA-hr43-rjmr-7wmm (folder mass-assignment, fixed
in v0.9.0); that fix did not generalize across the codebase, this fix
closes the feedback variant.
Co-authored-by: yantongggg <yantongggg@users.noreply.github.com>
* chore: trim comments
---------
Co-authored-by: yantongggg <yantongggg@users.noreply.github.com>
