SnapOtter CVE-2026-109562

Requires the attacker to possess a valid SnapOtter API key of ANY scope - the description confirms even a settings:read-scoped key is sufficient, because the /api/v1/upload, /api/v1/preview and /api/v1/preview/generate handlers sat outside both the requireFileAccess gate (which protected /api/v1/files) and the tool-access middleware (which only fired for /api/v1/tools/). The limiting factor is that unauthenticated callers cannot reach these routes; authentication alone, with no file or tool permission, was the only prerequisite. Affected deployments are SnapOtter versions 1.15.10 through 2.2.0; the fix is the referenced commit. The downstream unauthenticated exposure occurs via /api/v1/download serving the staged files.

This is a genuine but moderate-priority broken-access-control flaw, not a critical one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 MEDIUM score align well with the description: exploitation is network-reachable and low-complexity but requires an authenticated principal (PR:L) - the description explicitly notes even a settings:read-scoped API key suffices, confirming the low-privilege barrier. Impact is correctly scoped as limited (VC:N/VI:L/VA:L): no confidentiality loss, only low integrity (staging arbitrary files outside quota) and low availability (quota bypass plus feeding crafted input to image/video decoders). No EPSS score was provided and the vulnerability is NOT in CISA KEV, so there is no evidence of active exploitation; exploitation status is best characterized as no public exploit identified. A fix commit is public (1544966b) which discloses the exact vulnerable routes and the precise missing checks, lowering the bar for an attacker to reproduce the issue even though no weaponized PoC is provided. The decoder-feeding angle (Sharp, libheif, LibRaw, FFmpeg over caller-supplied bytes) is the most serious latent risk - it is a potential pivot to memory-safety bugs in those libraries - but that secondary impact is not itself quantified here. Net: a real issue worth patching, gated by requiring any valid API key, consistent across all signals.

An attacker who holds any low-privilege SnapOtter API key - even one scoped only to settings:read - sends requests directly to /api/v1/upload and /api/v1/preview, which never performed permission checks. They stage arbitrary files that bypass the storage quota and are then served to anyone unauthenticated through /api/v1/download, and they feed malformed media to the image/video decoders. No public exploit exists, but the public fix commit precisely identifies the three unguarded handlers.