CVE-2026-54741 in Lemmy
Summary
by MITRE • 08/20/2026
Lemmy is a link aggregator and forum for the fediverse. Prior to 0.19.19 and 1.0.0-alpha.18, Lemmy blocks new private messages from a sender after the recipient blocks that sender, but the edit path skips the same block check. create_private_message checks the recipient's block list with PersonActions::read_block before inserting a message, while edit_private_message in crates/api/api_crud/src/private_message/update.rs only checks that the caller is orig_private_message.creator_id. The update then writes new content and returns the modified PrivateMessageView without consulting the recipient's block list, allowing a blocked sender to keep changing an old message that the recipient can still see and providing a post-block harassment path. This issue is fixed in versions 0.19.19 and 1.0.0-alpha.18.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in Lemmy, specifically affecting versions prior to 0.19.19 and 1.0.0-alpha.18, represents a critical logic flaw within the private messaging subsystem that undermines user safety controls. As a link aggregator and forum software for the fediverse, Lemmy relies on robust access control mechanisms to ensure that users can effectively manage their interactions and block unwanted communications. The core issue arises from an inconsistency in how blocking permissions are enforced across different operations involving private messages. While the system correctly implements protection during the initial creation of new messages, it fails to apply the same security checks when existing messages are edited by previously blocked senders. This discrepancy creates a significant gap in the application's defensive posture, allowing malicious actors to bypass block lists through a specific manipulation of message metadata rather than creating new content.
From a technical perspective, the flaw stems from divergent validation logic between two distinct API endpoints or internal functions: create_private_message and edit_private_message. When a user attempts to send a new private message, the system invokes PersonActions::read_block to verify whether the recipient has blocked the sender. If a block exists, the operation is denied, effectively preventing harassment via new communications. However, when an existing private message is updated, the validation logic in crates/api/api_crud/src/private_message/update.rs only verifies that the caller matches the original creator_id of the message. This check ensures that only the author can modify their own content but completely omits any verification against the recipient's block list. Consequently, if a sender was blocked after sending an initial message, they retain the ability to continuously edit that same message. Since the edited version is still visible to the recipient and potentially propagated through feeds or notifications depending on client implementation, this constitutes a persistent harassment vector that circumvents the user's explicit wish for no contact.
The operational impact of this vulnerability allows for post-block harassment, which can have severe psychological and social consequences for users who rely on blocking features to maintain their digital well-being. An attacker could send an initial message, wait for or trigger a block action from the victim, and then repeatedly edit that same message with abusive, threatening, or harassing content. Because each edit is processed as a legitimate update by the application rather than a new communication attempt, the standard blocking mechanism fails to intercept it. This behavior not only violates user expectations of privacy and safety but also undermines trust in the platform's moderation tools. In federated environments where users may migrate between instances or interact with diverse communities, such inconsistencies can lead to fragmented security postures and increased vulnerability for end-users who assume that a block action is absolute across all interaction types.
This issue aligns closely with CWE-284, Improper Access Control, as the application fails to enforce consistent authorization policies across related operations. It also relates to CWE-693, Protection Mechanism Failure, where the security mechanism designed to prevent unauthorized access or harassment does not function correctly in all scenarios. From an ATT&CK perspective, this vulnerability facilitates persistence and exploitation of user trust by allowing continued interaction despite explicit denial of service through blocking features. The attack vector is classified as local within the context of the application logic but remote for the end-user, requiring only authenticated access to a valid account that has previously communicated with the target.
To mitigate this risk, users must upgrade immediately to version 0.19.19 or later, where the edit_private_message function has been patched to include the same block list verification as the creation path. Administrators of Lemmy instances should ensure their software is updated and monitor for any signs of abuse that might indicate exploitation before the patch was applied. For developers maintaining custom forks or integrating with older versions, it is imperative to manually implement a check against PersonActions::read_block within the private message update logic. This ensures that if a recipient has blocked a sender, no further modifications can be made to messages sent by that sender, thereby closing the loophole and restoring consistent enforcement of user-defined blocking preferences across all messaging operations.