CVE-2026-109562 in SnapOtter
Summary
by MITRE • 10/13/2026
SnapOtter 1.15.10 through 2.2.0 contains a missing authorization vulnerability that allows any authenticated principal to call the /api/v1/upload, /api/v1/preview and /api/v1/preview/generate handlers without permission checks. Attackers holding even a settings:read-scoped API key can stage arbitrary files outside storage quota, served unauthenticated via /api/v1/download, and feed crafted input to image and video decoders.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in SnapOtter versions 1.15.10 through 2.2.0 represents a critical failure in access control mechanisms within the application's API layer. Specifically, the endpoints /api/v1/upload, /api/v1/preview, and /api/v1/preview/generate lack proper authorization checks that restrict operations to authorized roles or scopes beyond basic authentication. This architectural flaw allows any authenticated user, including those possessing only minimal permissions such as settings:read-scoped API keys, to execute file upload and processing functions intended for administrative or higher-privileged users. The absence of these permission checks effectively bypasses the principle of least privilege, enabling low-level accounts to perform actions that should be strictly gated by role-based access control policies.
The operational impact of this vulnerability is severe due to its potential for arbitrary file staging outside of designated storage quotas. By exploiting the upload handler, an attacker can circumvent quota restrictions and store malicious files on the server's filesystem or associated cloud storage buckets without limit. These staged files are subsequently made accessible via the /api/v1/download endpoint, which serves them unauthenticated. This creates a persistent repository for attack payloads that do not require further authentication to retrieve, significantly lowering the barrier for subsequent exploitation phases. The ability to stage arbitrary files effectively turns the application into a vector for distributing malware or hosting phishing resources under the trust of the victim organization's domain.
Furthermore, the vulnerability extends beyond simple file storage to include risks associated with input validation and media processing. Attackers can feed crafted inputs directly to image and video decoders through the preview handlers. This exposure increases the risk of server-side deserialization vulnerabilities, buffer overflows, or remote code execution if the underlying libraries used for decoding these media formats contain unpatched flaws. Even in the absence of immediate exploitation via decoder bugs, the ability to inject malformed data into processing pipelines can lead to denial-of-service conditions through resource exhaustion or application crashes. The combination of unrestricted file uploads and exposure of processed content creates a multi-stage attack path that compromises both confidentiality and integrity.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, as the system fails to enforce appropriate restrictions on authenticated users attempting to access resources beyond their privileges. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, given that sensitive file operations are exposed without adequate safeguards. In terms of attack tactics, this vulnerability facilitates initial access and persistence via ATT&CK techniques such as T1505 Server Software Component: Web Shell or T1106 Native API Execution if the uploaded files lead to code execution. The unauthenticated download capability further supports data exfiltration scenarios by allowing attackers to retrieve staged payloads without triggering additional authentication logs that might alert security teams.
Mitigation strategies must prioritize immediate patching of SnapOtter to a version where these authorization checks are properly implemented and enforced for all API endpoints. Until patches are applied, network-level controls should be employed to restrict access to the affected API paths based on IP whitelisting or strict firewall rules limiting exposure to trusted internal networks only. Additionally, implementing Web Application Firewall (WAF) rules can help detect and block anomalous upload patterns or requests from accounts with insufficient privileges attempting to access administrative functions. It is also critical to review existing API key scopes within the organization's identity provider to ensure that no single token possesses excessive permissions that could be leveraged in this manner, adhering strictly to role-based access control best practices.