CVE-2026-110228: wallabag Stored XSS Vulnerability

CVE-2026-110228 Overview

CVE-2026-110228 is a stored cross-site scripting (XSS) vulnerability in wallabag versions 2.6.13 through 2.6.14. The flaw [CWE-79] allows authenticated users to host arbitrary HTML content on the server by triggering a failed Pocket HTML, Pocket CSV, or Shaarli import. When the import fails, the uploaded file is retained at the predictable path /uploads/import/<user-id>.html. An attacker can upload an HTML file containing script tags but no anchor elements, then share the predictable URL to execute JavaScript in a victim's wallabag session.

Critical Impact
Authenticated attackers can execute arbitrary JavaScript in the browser context of any wallabag user who visits the attacker-controlled upload URL, enabling session theft and account takeover.

Affected Products

wallabag 2.6.13
wallabag 2.6.14
Self-hosted wallabag deployments using default .htaccess configuration

Discovery Timeline

2026-10-13 - CVE-2026-110228 published to NVD
2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-110228

Vulnerability Analysis

The vulnerability resides in the wallabag import workflow handled by HtmlController.php. The controller accepts uploaded HTML files for Pocket HTML, Pocket CSV, and Shaarli imports. When the import parser fails to locate expected anchor elements in the uploaded file, the application discards the import but leaves the uploaded file at a deterministic location on disk.

The retained file is placed under /uploads/import/<user-id>.html, where <user-id> corresponds to the authenticated uploader. Because this path is predictable and served directly by the web server, any HTML or JavaScript inside the file executes in the wallabag origin when a victim loads the URL.

The stored XSS primitive gives attackers execution in a trusted browser context. Script running in that context can read session cookies, issue authenticated API requests, exfiltrate saved articles, and modify account settings.

Root Cause

Two defects combine to produce the vulnerability. First, the import controller does not delete the uploaded file after a parsing failure. Second, the default .htaccess configuration in web/.htaccess does not block direct retrieval of files under /uploads/import/ or enforce a safe Content-Type header. The combination allows raw HTML to be served from the application origin.

Attack Vector

An authenticated attacker crafts an HTML document containing a <script> payload but omits any <a> anchor elements expected by the Pocket or Shaarli parsers. The attacker submits the file through the standard import form. The parser fails because no bookmarks are found, but the file remains at /uploads/import/<attacker-user-id>.html. The attacker then distributes that URL to a logged-in wallabag user, and the payload executes in the victim's session.

The vulnerability requires low privileges (any authenticated account) and user interaction (victim must open the link). See the VulnCheck Advisory on Wallabag XSS and the HackMD Stored XSS Analysis for complete exploitation walkthroughs.

Detection Methods for CVE-2026-110228

Indicators of Compromise

Presence of unexpected .html files under the /uploads/import/ directory on the wallabag host
Web server access logs showing GET requests to /uploads/import/<user-id>.html from users other than the uploader
Failed import events in wallabag logs followed by direct access to the resulting file path
Outbound requests from browsers to attacker-controlled domains originating from the wallabag origin

Detection Strategies

Inspect uploaded files in /uploads/import/ for <script> tags or on*= event handler attributes
Correlate wallabag application logs for HtmlController import failures with subsequent HTTP GETs to the matching user ID path
Alert on any HTTP response from the wallabag host serving Content-Type: text/html from the /uploads/ tree

Monitoring Recommendations

Monitor file creation events under the wallabag web/uploads/import/ directory
Review authentication logs for anomalous session activity following user visits to internal wallabag URLs
Enable Content Security Policy (CSP) reporting to surface inline script execution attempts

How to Mitigate CVE-2026-110228

Immediate Actions Required

Audit the /uploads/import/ directory and remove any residual .html files from prior failed imports
Restrict import functionality to trusted users until a patched release is deployed
Deploy a Content Security Policy that forbids inline script execution on the wallabag origin
Configure the web server to block direct retrieval of files under /uploads/import/

Patch Information

At the time of publication, no fixed version is listed in the NVD entry for CVE-2026-110228. Monitor the Wallabag GitHub Repository for a release addressing versions after 2.6.14. Review the HtmlController Code Segment and the Wallabag .htaccess File to understand which code paths require remediation.

Workarounds

Add a web server rule denying HTTP access to /uploads/import/*.html or forcing a Content-Disposition: attachment header
Modify the .htaccess file to set Content-Type: text/plain for files served from the uploads directory
Implement a scheduled job that deletes files under /uploads/import/ older than a short retention window
Temporarily disable the Pocket HTML, Pocket CSV, and Shaarli import routes if import functionality is not required

bash

# Configuration example: block HTML execution from the uploads directory in Apache
<Directory "/var/www/wallabag/web/uploads/import">
    ForceType text/plain
    Header set Content-Disposition "attachment"
    Header set X-Content-Type-Options "nosniff"
</Directory>