CVE-2026-110228 in Wallabag
Summary
by MITRE • 10/13/2026
wallabag 2.6.13 through 2.6.14 contains a stored cross-site scripting vulnerability that allows authenticated users to host arbitrary HTML by triggering a failed Pocket HTML, Pocket CSV or Shaarli import. Attackers can upload an HTML file with script but no anchor elements, leaving it at the predictable /uploads/import/<user-id>.html path to execute script in victims' wallabag sessions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in wallabag versions 2.6.13 through 2.6.14 represents a significant security flaw classified as Stored Cross-Site Scripting, commonly referred to as Persistent XSS. This type of vulnerability is particularly dangerous because the malicious payload is stored on the target server and executed whenever a victim accesses the affected content, rather than being delivered via a one-time link. The root cause lies in insufficient input validation during the import process for external reading list services such as Pocket HTML, Pocket CSV, or Shaarli formats. When an authenticated user initiates an import operation that fails due to malformed data structures—specifically when an HTML file contains script elements but lacks required anchor tags—the application does not sanitize the content properly before storing it in the database and subsequent filesystem locations.
The technical mechanism of this exploitation relies on a predictable artifact creation within the server's directory structure. Upon triggering the failed import, wallabag saves the malicious HTML file to a static path defined as /uploads/import/<user-id>.html, where <user-id> corresponds to the identifier of the authenticated user who performed the action. This predictability allows an attacker to precisely locate the hosted payload without needing to enumerate dynamic URLs or session-specific tokens for retrieval. The stored script remains on the server indefinitely until manually removed by an administrator or through a system cleanup process, creating a persistent threat vector that does not require further interaction from the initial attacker after the upload is complete.
The operational impact of this vulnerability extends beyond simple defacement or local script execution within the context of the uploaded file itself. Because wallabag is typically used to manage personal reading lists and bookmarks, authenticated users often keep their sessions active for extended periods while browsing content. If another user with access privileges views a page that references or loads this malicious HTML artifact, or if the application inadvertently renders the stored script in any context such as search results, tags, or shared collections, the injected JavaScript will execute within the victim's browser session. This execution occurs under the security context of the wallabag instance, granting the attacker the ability to perform actions on behalf of the victim, steal sensitive cookies and authentication tokens, hijack sessions, or manipulate the user interface to phish for credentials.
From a classification perspective, this vulnerability aligns with CWE-79, which describes Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. The specific nature of storing malicious content on the server maps directly to CWE-80, Persistent Cross-Site Scripting. In terms of offensive security frameworks like MITRE ATT&CK, this behavior corresponds to techniques involving Stored XSS for initial access or persistence, and potentially Credential Access if session tokens are harvested. The attack chain leverages valid authentication credentials to upload content that is then served back to other users, exploiting the trust relationship between the client browser and the web application server.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For systems currently running affected versions, upgrading to a patched version of wallabag where input sanitization for import files has been rigorously enforced is the primary solution. Administrators should also audit existing uploads in the /uploads/import/ directory to identify and remove any previously stored malicious HTML files that may have exploited this flaw before patching occurred. From an application development standpoint, implementing strict allow-lists for permitted tags during file imports ensures that only safe structural elements are retained while stripping out script blocks entirely regardless of import success or failure status. Additionally deploying a Web Application Firewall with rules capable of detecting and blocking XSS payloads in POST requests can provide an additional layer of defense against similar injection attempts across the application surface.