Why is this changing?
For years, some deployments used a known workaround: a regular user session or personal access token (PAT) forged integration props such as from_webhook together with override_username / override_icon_url so posts appeared under a custom name and icon (often with a BOT badge).
That pattern is indistinguishable from impersonation. Channel UI, thread lists, push notifications, and post previews all honor those props once they are stored.
In MM-68754 / #36771 we started closing related spoofing surfaces, but left the from_* markers user-settable in v11 for backward compatibility. v12 is the agreed major-version window to finish that work (MM-69223).
Starting in v12.0, the server strips these props on create/update for non-federated posts and re-applies them only under verified integration authority.
Which props are affected?
| Prop | Behavior in v12 |
|---|---|
from_webhook, from_bot, from_oauth_app, from_plugin |
Stripped from client/PAT payloads; re-set by the server for bots, OAuth app sessions, incoming webhooks, slash commands, and plugins |
override_username, override_icon_url, override_icon_emoji, webhook_display_name |
Stripped from client/PAT payloads; re-applied only for incoming webhooks and slash commands, and only when the corresponding System Console override settings are enabled |
ExperimentalEnableHardenedMode no longer returns HTTP 400 for these reserved props. Hardened mode continues to control login/MFA/password-reset/5xx scrubbing only. Identity props are always stripped server-side, independent of that flag.
What will I see if my script still forges these props?
The post is created successfully, but the forged identity props are silently removed. The message appears as the authenticating user (or bot account), with that account’s normal username and profile image — not the forged override.
There is no new error code for this path; the values simply do not persist.
Are legitimate integrations affected?
No. Intended paths keep working:
- Incoming webhooks — username/icon overrides still work when enabled in System Console
- Slash commands — same override gates as today
- Bot accounts — posts as the bot user; use the bot’s account username/icon (per-post override via forged props is not supported)
- OAuth apps and plugins —
from_*markers are still set by the server from verified session/entry-point authority - Shared Channels / federation — remote identity props continue to be preserved across sync
What are my options?
Migrate PAT “custom name/icon” scripts to an incoming webhook. Create a webhook for the target channel and post with username / icon_url (or icon_emoji) in the payload. Enable “Enable integrations to override usernames” / “profile picture icons” if you need those overrides.
Migrate to a bot account. Create a bot, use its access token, and set the bot’s username and icon in System Console. Prefer this when the poster should be a durable identity rather than a one-off webhook display name.
Use a slash command if the workflow is already command-driven; response username / icon_url (and equivalent props) remain gated by the same System Console settings.
When does this take effect?
Mattermost v11 continues to allow the previous client/PAT prop behavior (subject to hardened mode if you enabled it).
Starting with Mattermost v12.0 (October 2026), default strip-and-reinject is always on.
If you rely on PAT forging today, migrate to a bot or incoming webhook before upgrading to v12.