CVE-2026-104051 in PictShare
Summary
by MITRE • 10/02/2026
PictShare before 3.7.1 contains an information disclosure vulnerability that allows unauthenticated attackers to obtain the secret delete_code and uploader metadata by calling the API::info() endpoint which returns the complete raw metadata object without a field whitelist. Attackers can use the publicly visible file hash to retrieve the delete_code via the info API and then invoke the delete API to permanently delete arbitrary files, while also exposing uploader IP, User Agent, remote port, and SHA-1 hash, resulting in loss of content integrity, availability, and uploader privacy.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in PictShare versions prior to 3.7.1 represents a critical failure in API design principles, specifically concerning the principle of least privilege and data minimization. The core technical flaw resides within the implementation of the api/info endpoint, which is designed to provide metadata about uploaded images but fails to implement any form of field whitelisting or output filtering mechanism. Instead of returning only necessary public information such as image dimensions or file type, the function returns the complete raw metadata object associated with each upload. This architectural oversight allows unauthenticated actors to access sensitive internal data structures that were intended for administrative use or secure backend processing rather than public consumption. The absence of input validation on the request side is less critical here than the lack of output sanitization, as the vulnerability stems from exposing too much information through a legitimate interface rather than exploiting an injection flaw in parameter handling.
From a technical perspective, this issue classifies under CWE-209: Generation of Error Message Containing Sensitive Information and CWE-749: Exposed Dangerous Method or Function within the Common Weakness Enumeration framework. The API endpoint acts as an information disclosure vector because it bypasses standard access controls that would typically restrict sensitive fields like authentication tokens, internal identifiers, or private user data to authorized sessions only. By returning the full metadata payload without filtering, the application inadvertently creates a side channel through which attackers can enumerate and extract high-value targets. The specific exposure of uploader IP addresses, User Agent strings, remote ports, and SHA-1 hashes provides adversaries with detailed reconnaissance capabilities that go beyond simple file listing. This level of detail allows for precise profiling of users and infrastructure, facilitating further targeted attacks such as session hijacking or network mapping based on the exposed network identifiers.
The operational impact of this vulnerability extends significantly beyond mere privacy loss. Because the delete_code is included in the unfiltered metadata response, an attacker can trivially retrieve it by querying any publicly accessible image via the info endpoint. With both the file hash and the corresponding secret delete code obtained without authentication, the attacker gains full control over the availability and integrity of stored content through the delete API. This transforms a simple information leak into a severe denial-of-service vector and potentially an integrity compromise if combined with other upload vulnerabilities. The ability to permanently remove arbitrary files undermines the reliability of the image hosting service for legitimate users and administrators. Furthermore, the exposure of uploader IP addresses and User Agent strings constitutes a significant privacy violation, potentially exposing individuals to doxxing or targeted harassment depending on the context in which PictShare is deployed.
In terms of threat modeling, this vulnerability aligns with ATT&CK technique T1005: Data from Local System and T1213: Data from Information Repositories, as it involves gathering data directly from a system component without direct access to the underlying file system or database. The attack path is straightforward and requires no prior authentication, making it highly exploitable by automated scanners and opportunistic attackers alike. The combination of information disclosure leading to unauthorized deletion creates a compound risk where confidentiality breaches directly enable availability attacks. This scenario highlights the danger of coupling sensitive operational data with public-facing endpoints without adequate separation of concerns or role-based access control enforcement at the API layer.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. The primary fix involves updating PictShare to version 3.7.1 or later, where this issue has been addressed by implementing strict field whitelisting for the api/info endpoint response. Administrators who cannot immediately upgrade should consider placing a reverse proxy in front of the application to filter responses and strip sensitive fields such as delete_code, uploader IP, and internal hashes before they reach the client. Additionally, reviewing API design practices is essential; all public-facing endpoints must adhere to strict output validation rules that explicitly define allowed data structures rather than relying on implicit trust or default serialization behaviors. Implementing rate limiting on these endpoints can also help mitigate automated scraping attempts while more permanent fixes are deployed. Regular security audits of API responses should be conducted to ensure no sensitive metadata is inadvertently exposed in future updates, reinforcing the need for defense-in-depth strategies that include both input validation and rigorous output sanitization protocols.