CVE-2026-109568 in Shaark
Summary
by MITRE • 10/13/2026
Shaark 1.2.13 through 1.2.44 contains a missing authorization vulnerability in the Link, Story, Chest and Album API controllers that skips ownership checks. Authenticated non-admin users can send PUT or DELETE requests to /api/{link,story,chest,album}/{id} with numeric IDs to overwrite or delete other users' content, including private items.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in Shaark versions 1.2.13 through 1.2.44 represents a critical failure in access control mechanisms within the application's API layer. Specifically, this flaw resides in the Link, Story, Chest, and Album API controllers, which are responsible for managing user-generated content such as shared links, narrative stories, digital chests, and photo albums. The core technical issue is a missing authorization check that bypasses ownership verification when processing HTTP PUT or DELETE requests directed at specific resource endpoints identified by numeric IDs. In a properly secured system, the server must validate not only that the requester is authenticated but also that they possess administrative privileges or are the legitimate owner of the target resource before allowing modification or deletion operations. Shaark fails to perform this validation step for these specific API routes, effectively treating all authenticated users as if they have unrestricted control over any content item accessible via its numeric identifier scheme.
From a technical perspective, this vulnerability allows an attacker who has valid credentials for any standard user account to manipulate data belonging to other users on the same instance. By constructing malicious HTTP requests with PUT or DELETE methods and targeting endpoints such as /api/link/{id}, /api/story/{id}, /api/chest/{id}, or /api/album/{id} using arbitrary numeric identifiers, an attacker can overwrite existing content or permanently delete it. This capability extends to private items that are not intended for public viewing, indicating a severe breach of data isolation principles. The reliance on sequential or predictable numeric IDs exacerbates the risk, as attackers can easily enumerate valid resource IDs and systematically target specific users' data without needing prior knowledge of internal application logic beyond the API structure itself.
The operational impact of this vulnerability is significant, affecting both data integrity and confidentiality within multi-user Shaark deployments. For individual users, it means that their private collections, shared links, or personal stories can be altered or erased by any other registered user on the platform. This undermines trust in the application as a secure repository for digital assets. In organizational contexts where Shaark might be used to share sensitive documents or curated content among team members, this flaw could lead to accidental data loss or malicious sabotage of shared resources. Furthermore, because the vulnerability affects multiple distinct modules (links, stories, chests, albums), it provides an attacker with diverse vectors to disrupt service availability and compromise user privacy simultaneously.
This issue aligns directly with CWE-284, which describes Improper Access Control, specifically highlighting failures in authorization checks that allow unauthorized actors to perform privileged functions or access restricted data. It also maps to the MITRE ATT&CK framework under T1078, Valid Accounts, as it requires initial authentication but leverages those credentials to escalate privileges implicitly through flawed logic rather than explicit privilege escalation techniques. The attack vector is classified as Remote with Low Complexity, requiring only network connectivity and valid user credentials, making it a high-risk vulnerability for any publicly accessible or internally shared Shaark instance.
To mitigate this risk, immediate action should be taken by upgrading the Shaark installation to version 1.2.45 or later, where these authorization checks have been corrected. Until an upgrade is feasible, administrators can implement compensating controls at the network perimeter level. This includes configuring Web Application Firewalls (WAF) rules to monitor and restrict PUT and DELETE requests to API endpoints that do not originate from expected administrative interfaces or IP ranges if applicable. Additionally, enforcing strict rate limiting on these specific API paths can help mitigate bulk enumeration attacks aimed at discovering valid resource IDs. Long-term remediation strategies should involve implementing a comprehensive review of all API controllers to ensure consistent ownership verification logic is applied uniformly across all data manipulation endpoints, thereby preventing similar gaps in other modules from being exploited in the future.