Lemmy CVE-2026-54741

Exploitation requires an active authenticated Lemmy account (PR:L) and that the attacker have sent at least one private message to the target recipient before the block was applied - the attacker can only edit pre-existing messages, not create new ones post-block. Private messaging must be enabled on the instance (check_private_messages_enabled is also added by the fix). The bypass is limited to the edit endpoint; the create path correctly enforces the block check. Unauthenticated users cannot exploit this. Attackers who never sent a prior message to the victim before being blocked have no message to edit and cannot exploit the flaw. There is no requirement for elevated roles, admin access, or any non-default instance configuration beyond private messaging being enabled.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) scores 5.3 Medium, accurately reflecting that exploitation requires authentication (PR:L) and produces only limited integrity impact (VI:L) with no confidentiality or availability consequence. The real-world risk is a harassment enablement path, not data theft or service disruption - a blocked user can persistently rewrite an old message to inject new unwanted content to the recipient. No CISA KEV listing and no public exploit code have been identified, making active widespread exploitation unlikely. EPSS data was not provided in the input and cannot be independently assessed. Attack complexity is low (AC:L) with no special timing or attack prerequisites (AT:N), so the mechanics are trivial for any authenticated user who previously messaged the victim. Despite the low severity tier, community-facing Lemmy instances should treat this as a prompt patching priority given the direct user safety implications of harassment bypass.

An authenticated Lemmy user sends a private message to a target, who then blocks the sender. The now-blocked sender crafts a standard API edit request to the edit_private_message endpoint referencing the original message ID and supplies new harassing content; the endpoint accepts the update without consulting the block list, persists the modified text, and returns the updated PrivateMessageView - the victim sees the new content despite having blocked the sender. No special tooling is required beyond a standard HTTP client or Lemmy API access.