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.