Anki CVE-2026-58266

The victim must actively import a malicious Anki card package (.apkg) - this is the required user interaction step reflected in CVSS UI:R. The attacker must embed a crafted iframe within a card that calls the exposed internal localhost API. Exploitation is constrained to files readable by the OS user account running Anki; it does not grant root or SYSTEM-level access beyond the process's own permissions. The vulnerability requires no authentication, no special network position, and no non-default Anki configuration - any installation of Anki prior to 25.09.4 with default settings is vulnerable upon import of a malicious deck. The critical limiting factor is the social engineering step: the victim must be convinced to import the deck.

The CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) reflects a realistic threat model: no attacker privileges or special configuration required, but a user interaction step (importing the malicious deck) limits automated exploitation. The Confidentiality impact is High, meaning an attacker can read arbitrary files accessible to the Anki process, including documents, credentials, SSH keys, and browser profiles depending on OS permissions. No EPSS probability data was provided in the input. No CISA KEV listing exists, and no public POC exploit code has been identified, indicating this is not currently under widespread active exploitation. The social engineering surface is non-trivial - Anki's large user community regularly shares and imports deck packages from community repositories, making malicious deck distribution a plausible and low-friction attack vector. Scope is unchanged (S:U), so compromise does not directly pivot to other systems, but exfiltration over the network makes this a meaningful data-theft risk for individual users.

An attacker publishes a malicious Anki deck package (.apkg) - disguised as a legitimate study resource - to a community sharing site or delivers it via phishing. When a victim imports the deck, an embedded iframe loads and calls the unprotected internal localhost API method getImageForOcclusion or similar endpoints to read sensitive files (e.g., SSH private keys, stored credentials) from the victim's filesystem and transmits them to an attacker-controlled server via outbound HTTP. No public POC exploit code has been identified at time of analysis, but the described attack path is straightforward given the documented API exposure.