LinkStack CVE-2026-7502

The attacker must be an authenticated user with a valid session on the LinkStack instance - unauthenticated remote exploitation is not possible (CVSS: PR:L). The vulnerable endpoints (saveLink, sortLinks, clearIcon) must be accessible via the Management Endpoint, which is the default configuration. No special configuration or feature enablement is required; the vulnerability exists in the default code path for any authenticated user attempting to modify links. The attack requires knowledge of another user's link IDs (trivial to enumerate via sequential ID guessing given AC:L) but not their credentials. Exploitation is limited by the fact that only link metadata is modified; the attacker cannot read the contents of other users' links due to the integrity-only impact (I:L).

CVSS 5.4 with network vector and low complexity indicates moderate baseline risk, but the full risk picture requires careful assessment. The CVSS vector shows PR:L (authenticated required), which significantly limits attack surface - an attacker needs valid credentials. However, the presence of publicly available exploit code (POC=YES) combined with the simplicity of IDOR attacks (AC:L, no user interaction) elevates practical risk for multi-user deployments where compromised or attacker-registered accounts exist. The E:P (Exploit: Proof-of-Concept) CVSS modifier confirms public disclosure. The vulnerability impacts integrity (I:L) and availability (A:L) of user data but not confidentiality, suggesting link manipulation or deletion rather than data exfiltration. The fact that the patch awaits PR acceptance (not yet merged) means vulnerable code remains in all released versions up to 4.8.6. For organizations running shared LinkStack instances (e.g., SaaS, multi-tenant deployments), this is a real priority: any user account compromise or registration by an attacker grants ability to tamper with other users' links. For single-user or tightly controlled deployments, risk is lower but not negligible if credential compromise is plausible.

An attacker with valid LinkStack credentials (obtained through registration on a public instance, credential reuse, or account compromise) sends a request to modify another user's link by supplying a different user's link ID in the saveLink endpoint (e.g., POST /api/links/modify?id=123 with modified link data). The application fails to verify that the attacker owns link ID 123, allowing the attacker to change the target URL, description, or other properties of the victim's link, or delete it entirely. Publicly available exploit code (as referenced in the GitHub security advisory) demonstrates this attack pattern.