wallabag Android EUVD-2026-67402

The attacker must be able to inject malicious content into an article visible to the victim's wallabag account - requiring either low-privilege authenticated access to the wallabag backend (PR:L per CVSS) or the ability to cause the victim to save a URL whose content contains a script payload. The victim must then open and view the malicious article in the Android app (UI:P - passive user interaction). Exploitation is limited to the Android client specifically; the web interface is not affected by this CVE. Scope-change exploitation (SC:H/SI:H) depends on whether the application's WebView exposes JavaScript bridges or file-system access beyond default sandboxing. The AT:P qualifier confirms a specific target condition (article must reach the victim's reading queue) rather than a blind network attack against arbitrary users.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:L/SC:H/SI:H/SA:L) reflects a network-reachable, low-complexity flaw requiring low privileges and passive user interaction, with high confidentiality and integrity impact across both the vulnerable system and a subsequent system - indicating the WebView scope-change concern. The AT:P (attack requirements present) qualifier is noteworthy: exploitation depends on the attacker being able to inject malicious content into an article the victim saves or is served, which is the primary limiting condition. EPSS data is not present in the input. No CISA KEV listing was provided, so active in-the-wild exploitation is not confirmed. A publicly available POC exists and references specific production source files, lowering the barrier to weaponization. The scope-change markers (SC:H/SI:H) suggest that a successful exploit could affect resources beyond the isolated WebView sandbox - consistent with WebView JavaScript bridges or file access misconfigurations. Overall: elevated real-world risk for users of self-hosted wallabag instances where an attacker can plant articles, but not a mass-exploitation scenario against default deployments.

An attacker with the ability to add an article to a victim's wallabag account - either via a compromised account, a shared instance, or by tricking the user into saving a malicious URL - embeds a JavaScript payload in the article body. When the victim opens the Android app and reads the article, the wallabag client fetches the content from /api/entries and loads it unsanitized into the WebView, executing the attacker's script. Depending on WebView permissions configured in the app, the script could exfiltrate session tokens, read locally cached articles, or leverage any JavaScript-to-native bridges exposed by the application.