EUVD-2026-97891
GHSA-33mg-5c73-726g
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged Shaark user
-
ExploitEnumerate sequential numeric content IDs
-
ExecutionSend PUT/DELETE to /api/{link,story,chest,album}/{id}
-
ImpactOverwrite or delete other users' private content
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Requires a valid authenticated non-admin user account on a multi-user Shaark instance (PR:L); the attacker then issues PUT or DELETE requests to the /api/{link,story,chest,album}/{id} routes using guessable sequential numeric IDs, because these controllers call findOrFail() without any owner check. Limiting factors: single-user/self-only deployments have no victim content to target, and the instance must allow the attacker to obtain an account (open registration or an existing multi-tenant setup); no user interaction is needed and the affected API accepts the requests against default configurations once authenticated. |
| Impact | This is a genuine but moderate-priority authorization flaw (CWE-639, IDOR). The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L, base 7.1) is internally consistent with the description: network-reachable API, low attack complexity, and crucially PR:L - exploitation requires an authenticated non-admin account, which is the single biggest mitigating factor. The GitHub PR #110 diff concretely confirms the root cause (missing |
| Exploit ScenarioDerived | An attacker registers or already holds a low-privileged (non-admin) account on a multi-user Shaark instance. They send a PUT or DELETE request to /api/link/{id} (or /story, /chest, /album) iterating numeric IDs, overwriting or destroying links, stories, chests and albums belonging to other users - including private items - because the controllers never verify ownership. No public exploit code was provided, but the trivial attack complexity and the published patch make a working request easy to construct. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Broken object-level authorization in Shaark 1.2.13 through 1.2.44 lets any authenticated non-admin user overwrite or delete other users' links, stories, chests, and albums by sending PUT or DELETE requests to /api/{link,story,chest,album}/{id} with sequential numeric IDs, because the API controllers load records with findOrFail() and never verify that the underlying post belongs to the calling user. Integrity impact is high (content can be modified or destroyed, including private items) while confidentiality is not affected and availability impact is limited; exploitation requires a valid low-privilege account on a multi-user instance, and the attacker must be able to obtain one via open registration or an existing tenant. This is a genuine but moderate-priority IDOR-class flaw (CWE-639); no public exploit code or confirmed in-the-wild activity was identified at time of analysis, and single-user or self-only deployments have no victim content to target.
RemediationAI
The authoritative fix is the ownership-enforcement patch in https://github.com/MarceauKa/shaark/pull/110, which adds a $model->post->user_id !== $request->user()->id check (returning HTTP 403) to the update and delete handlers in the link, story, chest, album, link-archive, and share API controllers; because this arrives as an upstream pull request rather than a tagged release, patched-version availability is not independently confirmed, so operators should upgrade to the earliest Shaark release that includes PR 110 or, failing that, apply the diff to their deployment and rebuild. Where code cannot be changed immediately, compensating controls are limited and each carries a trade-off: restrict or block PUT and DELETE methods to /api/link/{id}, /api/story/{id}, /api/chest/{id}, and /api/album/{id} at the reverse proxy for all non-administrative callers, accepting that legitimate users lose the ability to edit or delete their own content through those endpoints; or disable self-service account registration and remove untrusted accounts so that only a single trusted principal exists, which removes the victim set but does not fix the flaw and does not protect shared/multi-tenant instances. Post-exploitation, administrators should review server and application logs for PUT/DELETE activity on numeric IDs inconsistent with the authenticated account, check for deleted or altered private posts, and rotate nothing - this is an authorization flaw, not a credential compromise, so no secret material is exposed. Advisory URLs for tracking: https://www.vulncheck.com/advisories/shaark-1.2.13-through-1.2.44-missing-authorization-via-api-update-and-delete-routes and https://github.com/MarceauKa/shaark/pull/110.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Shaark is a Laravel-based self-hosted content/bookmarking application in which links, stories, chests, and albums are modeled as child records attached to a parent Post that carries the owning user_id. The vulnerable API controllers (app/Http/Controllers/Api/LinkController.php, StoryController.php, ChestController.php, AlbumController.php, and also LinkArchiveController.php and ShareController.php) resolve the target row directly from the user-supplied route parameter using findOrFail($id) and then immediately perform the update or delete, with no comparison of $model->post->user_id against $request->user()->id. This is the classic CWE-639 Authorization Bypass Through User-Controlled Key pattern: the object identifier is supplied by the client, the endpoint is reachable by any authenticated principal, and the authorization decision that should bind the object to its owner is simply absent. Because identifiers are monotonically increasing integers, enumeration is trivial and requires no special tooling. The upstream fix in pull request 110 adds eager loading of the post relation and an explicit ownership gate - $link = Link::with('post')->findOrFail($id); if ($link->post->user_id !== $request->user()->id) { abort(403); } - applied across the update and delete handlers, confirming the root cause is missing row-level ownership enforcement rather than a routing or authentication defect. Note the CVSS 4.0 vector supplied with the record shows PR:L (low privileges required), AV:N (network reachable) and VI:H (high integrity impact), matching the independent CVSS 3.1 assessment of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Network API with low complexity but requires an authenticated non-admin account (PR:L); overwrite/delete of others' content gives I:H and some availability loss (A:L), with no data disclosure so C:N.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
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.
Executive ViewAI
Shaark versions 1.2.13 through 1.2.44 carry an access-control flaw that allows any user holding a basic account to modify or permanently delete other users' links, stories, chests and albums - including private items and content belonging to other tenants - on multi-user instances. Because no vendor patch is available yet, every organization running an affected release remains exposed for the foreseeable future and must rely on configuration restrictions, monitoring and backup discipline to contain the risk. Exposure is limited to multi-user deployments where attackers can obtain an account through open registration or an existing tenant, but the resulting loss and destruction of user content should be treated as a priority for security and product leadership.
No vendor-released patch identified at time of analysis. Interim mitigations: disable or administratively gate open registration so attackers cannot self-provision a low-privilege account; restrict the instance to single-user or trusted-tenant operation where multi-tenancy is not required; block or filter non-administrator PUT and DELETE requests to the /api/link, /api/story, /api/chest and /api/album endpoints at the reverse proxy or WAF; enforce least-privilege role assignment and shorten session lifetimes; enable detailed request logging and alert on sequential-ID access patterns or cross-owner write and delete activity; maintain frequent, tested, offline backups of links, stories, chests and albums to enable restoration of destroyed or altered content; and isolate affected instances on a segmented network segment until a fixed release above 1.2.44 is available and deployed.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB