CVE-2026-54741

This vulnerability in Lemmy's private messaging stems from a fundamental inconsistency: the create_private_message endpoint correctly queries PersonActions::read_block before allowing a message to be sent, but edit_private_message only verifies that the caller authored the original message. If a recipient has blocked the sender, that block should prevent all interaction—not just new message initiation. The gap matters because private messages in a forum context carry social metadata visible to all participants in a thread. A blocked sender editing an old message reshapes what every reader believes was communicated, extending the blast radius beyond the direct recipient. Additionally, in the federated fediverse, block lists are instance-specific while edit permissions follow the message across instances—creating enforcement gaps where a sender blocked on one server can still manipulate messages visible to users on another. The deeper issue is architectural: Lemmy lacks a shared layer—guard, trait, or query builder extension—that enforces block-list checks as a default for all user-to-user content operations. Each endpoint manually implements (or omits) this logic, making consistent enforcement dependent on developer discipline rather than system design. The correct fix introduces shared validation infrastructure rather than duplicating the inline check from the create path. For defenders: audit all edit/update endpoints for user-generated content (posts, comments, community actions) for similar block-list and mute-list gaps. Check whether create paths in your codebase were retroactively hardened while corresponding edit paths were overlooked. Prioritize federated instances in your network—this vulnerability's reach extends across server boundaries, and coordination delays in a decentralized network compound exposure windows.

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