CVE-2026-96271 in Photoview
Summary
by MITRE • 09/23/2026
Photoview through 2.4.0 contains an authorization bypass vulnerability in the shareAlbum GraphQL mutation that allows authenticated users to create share links for albums owned by other users. Attackers can supply arbitrary album IDs to generate working share tokens for victim albums, exposing photos and sub-albums to anyone with the link while retaining indefinite control over token settings.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in Photoview versions up to 2.4.0 represents a critical authorization bypass within the application's GraphQL API layer, specifically targeting the shareAlbum mutation. This flaw stems from an insufficient server-side validation of ownership claims when processing requests to generate sharing tokens for photo albums. In a properly secured implementation, any operation that modifies access controls or generates public links for resources owned by other users must strictly verify that the requesting authenticated user is the legitimate owner of the target resource. However, in this instance, the application fails to enforce these identity checks against the album identifier provided in the request payload. Consequently, an attacker who has successfully authenticated with a valid account can manipulate the input parameters to reference albums belonging to other users within the system.
From a technical perspective, the core issue lies in the lack of integrity verification for the resource ownership context during the execution of the shareAlbum mutation. When a user submits a request containing an arbitrary album ID, the backend processes this identifier without cross-referencing it against the authenticated session's associated data or permissions matrix. This oversight allows the generation of valid sharing tokens that are cryptographically sound but semantically invalid regarding access rights. The resulting token grants read-only access to the specified album and its nested sub-albums to anyone who possesses the link, effectively bypassing the intended privacy boundaries established by the album owner.
The operational impact of this vulnerability is significant for user privacy and data confidentiality. Since Photoview serves as a personal photo management platform, users expect their images to remain private unless explicitly shared with trusted individuals through controlled mechanisms. By exploiting this flaw, an attacker can expose sensitive photographs, metadata, and organizational structures to the public internet without the knowledge or consent of the album owner. Furthermore, because the vulnerability allows for indefinite control over token settings, the exposure is not transient; it persists until manually revoked by the victim, creating a long-term security risk that undermines trust in the platform's data isolation capabilities.
This flaw aligns with CWE-284, which describes Improper Access Control, as well as CWE-639, Injection of Critical Data into an Authorization Mechanism, due to the manipulation of input parameters to bypass authorization checks. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1078, Valid Accounts, where attackers leverage legitimate credentials to perform unauthorized actions that are typically restricted by role-based or ownership-based policies. The vulnerability highlights a common pitfall in GraphQL implementations where the flexibility of query structures can lead developers to overlook strict resource-level authorization checks for every mutation endpoint.
To mitigate this risk, immediate patching to version 2.4.1 or later is required, as these versions include fixes that enforce proper ownership validation on all album-related mutations. For organizations unable to upgrade immediately, implementing a Web Application Firewall rule set can help detect and block requests where the authenticated user ID does not match the owner ID of the target resource in shareAlbum calls. Additionally, developers should conduct a thorough audit of other GraphQL endpoints to ensure that similar authorization checks are consistently applied across all data modification operations, ensuring that access control decisions are always made based on verified identity rather than untrusted client-supplied identifiers.