---
id: "GHSA-3vvh-g22g-jq6r"
page: "https://infrastack.ai/live/GHSA-3vvh-g22g-jq6r"
kind: "vulnerability"
aliases: ["GHSA-3vvh-g22g-jq6r"]
title: "Channel members can post messages shown as a webhook via client-supplied message metadata"
severity: "medium"
cvss: 4.3
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "open-webui", "fixed": ["0.12.2"], "affected": ">= 0.7.0, < 0.12.2", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-tooling", "channels", "cwe-290", "cwe-345", "cwe-863", "open-webui", "python", "self-hosted", "webhooks"]
not_affected_if: ["channels-disabled", "no-channel-webhooks", "version-0.12.2-or-later"]
published_at: "2026-10-18T19:50:50+00:00"
first_seen_at: "2026-11-09T22:53:28+00:00"
updated_at: "2026-11-09T22:57:12+00:00"
sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-3vvh-g22g-jq6r", "first_seen_at": "2026-11-09T22:53:28+00:00"}]
exploit_sources: []
---

# Channel members can post messages shown as a webhook via client-supplied message metadata

Link for people: https://infrastack.ai/live/GHSA-3vvh-g22g-jq6r (this .md is for agents)

Open WebUI stored client-supplied message metadata without checking it, so a channel member can post a message that displays under a channel webhook's name and role. An attacker can use this to deceive other channel members, such as those who trust an alerting or ops bot, but cannot read new data or use the webhook's token.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:open-webui affected >= 0.7.0, < 0.12.2 fixed 0.12.2

## How to check

- Check whether `ENABLE_CHANNELS` is set to `true` on the instance.
- Check whether any channel has at least one webhook configured.
- Check the installed Open WebUI version, for example with `pip show open-webui`; versions from `0.7.0` up to but not including `0.12.2` are affected.

## Fix

- `open-webui` `0.12.2` (fixed in #32421; the server now drops client-sent message metadata on post and edit, and upgrading is enough).

## Timeline

- 2026-11-09T22:53:28+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-3vvh-g22g-jq6r

## Documents

- [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-3vvh-g22g-jq6r

## From the sources

# Channel members can post messages shown as a webhook via client-supplied message metadata

## Summary
Any member who can post in a channel can make their message appear as if a real webhook of that channel posted it. The server stored the metadata the client sent with a message without checking it. The channel then showed the message under the webhook's name and role, with no webhook token required.

## Preconditions
Channels are enabled (`ENABLE_CHANNELS`, default `False`). The channel has at least one webhook. The attacker is a member with write access to the channel. The attacker knows the webhook's id. Any member can read it from a message the webhook posted, so it is not a secret. Instances with channels disabled, or without channel webhooks, are not affected.

## Impact
A member can post, edit and pin messages that other members see as coming from a trusted webhook, such as an alerting or ops bot. That makes social engineering inside the channel easy. The stored author is still the attacker's account. The attacker cannot change the webhook's real messages, read anything new or act with the webhook's token.

## Fix
Fixed in #32421. The server now drops any message metadata sent by the client, both when a message is posted and when it is edited, so only the server sets it. Upgrading is enough.

## Root cause
Component: the channel message post and edit endpoints in `backend/open_webui/routers/channels.py`. Affected setup: every build with channel webhooks, from 0.7.0. The message form accepted an arbitrary metadata object from the client and stored it as is. The message list and the pinned list then trusted that metadata to decide who the message was from. A webhook id in the metadata was enough for the message to be shown as that webhook.

## Proof of concept
1. Admin creates a webhook "Ops Bot" in a channel, and the webhook posts a message.
2. Alice, a channel member, reads the webhook id from that message.
3. Alice posts a message with `meta.webhook = {"id": "<webhook id>", "name": "Ops Bot"}` and pins it.
4. Bob opens the channel. The message and the pinned list show it as `Ops Bot` with role `webhook`, while the stored author is Alice.

Run by the reporter on 0.11.3.

## Credits
@Tarekinh0 (reporter)

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_
