CVE-2026-103974 in Lila
Summary
by MITRE • 10/14/2026
lichess.org is the forever free, adless and open source chess server. Prior to commit c54596c9e1569d378fe20f80d4c790c6fdee54c4, a user who can add a chapter to a study can place attacker-controlled text in the PGN Annotator tag, which becomes Comment.Author.External and is returned verbatim by authorText. When a study node has at least two comments, ui/analyse/src/treeView/inlineView.ts interpolates that author string into HTML passed to the innerHTML hook without escaping it. Opening the affected study can therefore render stored attacker-controlled HTML and CSS for other viewers, including navigation to an attacker-controlled site, content spoofing, and CSS-based data exposure, although the site's content security policy blocks injected JavaScript. This vulnerability is fixed by commit c54596c9e1569d378fe20f80d4c790c6fdee54c4.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in lichess.org represents a classic instance of stored cross-site scripting, specifically manifesting as HTML injection within the platform's study analysis feature. The root cause lies in the improper handling of user-supplied input during the creation and rendering of chess studies. Specifically, when a user with permissions to add chapters to a study provides text for the PGN Annotator tag labeled Comment.Author.External, this data is stored on the server without adequate sanitization or encoding. The flaw becomes critical in the client-side JavaScript code located at ui/analyse/src/treeView/inlineView.ts, which manages the display of comments associated with specific chess nodes. When a study node contains two or more comments, the application logic interpolates the author string directly into an HTML template and assigns it to the innerHTML property of a DOM element. This operation bypasses standard escaping mechanisms, allowing any valid HTML tags embedded in the author field to be parsed and rendered by the browser as active markup rather than plain text.
From a technical perspective, this flaw constitutes a Stored Cross-Site Scripting vulnerability because the malicious payload is persisted on the server's database via the study metadata and subsequently served to other users upon viewing the affected content. Although lichess.org employs a Content Security Policy that successfully blocks the execution of injected JavaScript scripts, preventing more severe attacks such as session hijacking or keylogging through script injection, it does not mitigate risks associated with HTML structure manipulation. The attacker can still inject arbitrary CSS styles and structural elements like anchor tags. This limitation allows for sophisticated social engineering attacks where the visual presentation of the chess interface is altered to mimic legitimate site components or external links. For instance, an attacker could style a link to appear as part of the game board while actually directing users to a phishing domain designed to steal credentials or distribute malware.
The operational impact of this vulnerability extends beyond simple defacement. It enables content spoofing and UI redressing attacks that can deceive legitimate users into interacting with malicious elements disguised within the trusted interface of lichess.org. Furthermore, CSS-based data exposure techniques could potentially be employed to exfiltrate information visible on the user's screen by manipulating layout properties such as overflow or text-indentation in conjunction with external requests triggered by pseudo-elements like :before and :after. While the CSP mitigates script execution, it does not prevent these structural attacks which rely solely on HTML and CSS features available within standard browser rendering engines. The persistence of this payload means that every user who views a compromised study is exposed to the risk, creating a wide attack surface across the community without requiring any immediate action from the victim other than browsing the site.
To mitigate such vulnerabilities, developers must implement strict output encoding for all dynamic content inserted into HTML contexts using innerHTML or similar methods. The primary defense involves ensuring that user-supplied data is treated as text rather than executable markup by escaping special characters such as less-than and greater-than signs before insertion into the DOM. Additionally, implementing a robust Content Security Policy with nonces or hashes can provide an additional layer of protection against script injection, although it must be complemented by proper input validation on both client and server sides. In this specific case, the vulnerability was addressed in commit c54596c9e1569d378fe20f80d4c790c6fdee54c4, which likely introduced sanitization logic to strip or encode HTML tags within the Comment.Author.External field before storage. Security teams should audit similar input fields across their applications for consistent handling of rich text inputs and ensure that any user-controlled data rendered in DOM contexts is properly escaped according to OWASP guidelines.
This incident aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. The attack vector falls under MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter subcategories if scripts were executable, but in this context, it relates more closely to UI Redressing (T1647) due to the CSS-based manipulation capabilities enabled by the HTML injection. Organizations should prioritize regular security code reviews focusing on data flow from user inputs to DOM rendering functions to prevent similar structural vulnerabilities that bypass script-blocking CSPs through legitimate browser features.