Blinko EUVD-2026-101574

Exploitation requires a valid authenticated low-privileged account on the target Blinko instance (PR:L) and is limited to deployments running Blinko through version 1.8.8. The attacker must additionally supply the victim's exact stored filename, which follows a basename-plus-millisecond-timestamp pattern - this predictability is the enabling condition but also a partial limiter (reflected as AT:P), since filenames must be known or reconstructed rather than being directly enumerable. The flaw affects reads of private, non-shared attachments specifically; shared attachments are not the target. Impact is confined to confidentiality - no modification or denial of service - and multi-user/multi-tenant deployments are the realistic risk surface, since a single-user instance has no other users' attachments to expose.

This is a moderate-severity, authorization-level information-disclosure flaw (CWE-639, IDOR) rather than a high-urgency issue. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N) correctly captures the shape: network-reachable but requiring an authenticated low-privileged account (PR:L) and carrying an attack requirement (AT:P) - the attacker must know or reconstruct the victim's stored filename, which follows a predictable basename-plus-millisecond-timestamp pattern. Impact is confidentiality-only (VC:H, VI:N, VA:N): private, non-shared attachments can be read, but nothing is modified or taken offline, and there is no scope change. No EPSS score, no CISA KEV listing, and no vendor-flagged POC were provided, so there is no evidence of active or widespread exploitation - the signals are internally consistent (a serious-but-bounded authz bug), not conflicting. The main caveat is that a detailed public technical writeup exists (the hackmd advisory and the VulnCheck advisory pinpoint the exact vulnerable code at file.ts#L148), which lowers the bar to reproduce exploitation even though no packaged exploit is listed. Net: a legitimate fix-it-on-schedule priority for anyone running Blinko multi-user, but not an emergency, given the authentication requirement, the confidentiality-only impact, and the absence of KEV/EPSS escalation signals.

An attacker who holds a legitimate low-privileged account on a shared Blinko instance (through 1.8.8) targets the /api/file route and supplies a filename belonging to another user, reconstructed from the predictable basename plus millisecond-timestamp naming pattern. Because the owner check is flawed, the server returns the victim's private, non-shared attachment to the attacker. A public technical writeup detailing the IDOR and the exact vulnerable code path exists, though no packaged exploit was reported in the input.