CVE-2026-54743

This CVE exposes a subtle but critical security boundary failure in how Lemmy processes markdown. The core issue: when you configure markdown-it's `html:false` setting, you expect NO HTML to render from user input. But the html5-embed plugin operates outside this boundary—it generates raw HTML as plugin behavior, not as markdown parsing output. The Lemmy team appears to have trusted `html:false` as their sanitization boundary when it only governed the core parser. The existence of `mdToHtmlNoImages` is the forensic tell. Someone on the team recognized the HTML generation risk and created a safer alternative, but it was applied inconsistently—post bodies, comments, and private messages still use the unsafe `mdToHtml` variant. This isn't a documentation trap; it's evidence of known risk that was partially mitigated but allowed to persist in other code paths. Security got addressed at the function level rather than enforced across the entire rendering pipeline. For self-hosted deployments, the CVSS 6.4 rating is misleading. The advisory lists CSP as a mitigating factor, but default Lemmy installations serve no CSP headers. The primary deployment model—self-hosted with no CSP—effectively has no mitigation, meaning the real-world severity for most affected users is higher than the score suggests. The federated architecture amplifies this beyond a typical XSS. Malicious content from a compromised instance federates to every connected instance and persists indefinitely—remote instances can store and replay payloads long after you've patched your own server. You patched your instance? Congratulations—your users still render crafted alt text from federation partners who never updated. If you're running Lemmy, prioritize three things: First, enable a strict Content Security Policy header to mitigate script execution even if HTML injection occurs. Second, audit your rendering paths—search the codebase for `mdToHtml` calls and migrate them to `mdToHtmlNoImages` or implement post-render sanitization. Third, recognize that patching your instance doesn't protect you from federated content; you need to consider which remote instances you're federating with and whether they've applied the fix.

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