KeePassXC EUVD-2026-113213

Exploitation requires a local client that can reach KeePassXC's per-user browser IPC endpoint (the per-user named pipe/socket), possess a valid database association key (a completed test-associate/change-public-keys handshake), and face an already-unlocked database. Additionally, a sufficiently large authorized response must be generated - concretely demonstrated with ~180 matching entries carrying ~8 KiB titles so the encrypted ciphertext exceeds the fixed NATIVEMSG_MAX_LENGTH of 1,048,576 bytes (crossover observed near 8,161-character titles). The overflow is built only after the relevant entries are authorized: this happens automatically when Browser/AlwaysAllowAccess=true or when entries were previously approved, but under the DEFAULT policy (AlwaysAllowAccess=false) KeePassXC awaits interactive user approval and the process survives if approval is withheld - a significant real-world limiter. The practically meaningful scenario is a compromised or malicious but already-authorized browser extension that is sandboxed from the native process; a native-privilege attacker could terminate KeePassXC directly, so the added DoS value there is marginal.

The input CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:P/VC:N/VI:N/VA:H) yields a base score of 4.1 (MEDIUM), and the signals are internally consistent for a low-to-moderate priority issue rather than an urgent one. Multiple barriers stack: the attack vector is local to the per-user browser IPC endpoint (AV:L), it requires a valid database association (PR:L), it depends on specific heap/response conditions and user-approval timing (AC:H plus AT:P), and the only impact is availability (VA:H) - the reporter explicitly observed no confidentiality or integrity impact. The confirmed outcome is a reliable KeePassXC process crash/denial of service; the reporter, after a Microsoft CDB assessment, expressly did NOT claim RCE, instruction-pointer control, or credential disclosure. There is no CISA KEV listing (so this is not confirmed actively exploited) and no EPSS score was provided in the input, so exploitation probability cannot be quantified here. The vuln.today decision label is 'this_month' - a routine patch priority, not act_now or emergency. A detailed public PoC/reproduction methodology exists in the GHSA advisory, but the stated impact ceiling is DoS, and in the most security-relevant scenario (a sandboxed, already-authorized browser client that cannot otherwise touch the native process) the realistic gain is only crashing KeePassXC. Overall this is a genuine memory-safety defect but a bounded one, better characterized as medium-severity DoS than a high-risk emergency.

A malicious or compromised browser extension (or other client that can reach the per-user KeePassXC named-pipe/IPC endpoint) that already holds a valid association key and faces an unlocked database issues a get-logins request whose authorized response is large enough - e.g. many matching entries with multi-kilobyte titles - that the encrypted output exceeds the fixed 1 MiB buffer. KeePassXC's crypto_box_easy() call then performs a sequential out-of-bounds write while building the response, reaching a reserved no-access page and crashing the process (0xC0000005) before any response is returned. A public PoC reference with full reproduction steps exists in the GHSA advisory; it is not published as a ready-to-run weaponized exploit, and the demonstrated impact is denial of service only.