CVE-2026-70481

This vulnerability exposes a fundamental confusion in how the permission model treats channel access versus message ownership. Any participant in a standard channel could modify or delete messages authored by other users — a capability that was correctly restricted in direct messages and group chats but inexplicably absent for standard channels. The critical insight: developers understood authorship checks. They implemented them correctly for DMs and groups. The omission in standard channels was not accidental ignorance — it reflected a flawed design assumption that channel-level write permission grants message-level mutation authority over all content in that channel. This conflates spatial access with object ownership, like assuming that being allowed into a room gives you the right to rewrite anything written on its walls. What makes this particularly severe is the blast radius. The platform effectively operated under three incompatible permission models simultaneously. Users participating in all three channel types had completely different trust contracts with each, invisible from the interface. Every message written in any standard channel for three years — across six releases — was technically mutable by any participant who understood the API. The CVSS 5.4 score measures the technical properties of the individual action (low privilege, no interaction) but fundamentally underweights the compound damage: silent, permanent modification of collaborative content with no audit trail visible to the victim. The fix is straightforward — add authorship checks to standard channel message handlers to match the DM/group implementation. But the deeper remediation is architectural: audit all analogous code paths for inconsistent application of security invariants. The correct pattern existed in the codebase the entire time; organizational silos prevented cross-referencing it during security reviews. The vulnerability is a textbook case of security understanding debt, where improvements in one part of the system fail to propagate to older code paths. Check your codebase for similar divergences — wherever you have analogous features with different permission enforcement, treat the inconsistency as a potential vulnerability until proven otherwise.

Reviewed through automated stages and approved by a human before publication.