Which versions of LinkAce are affected by CVE-2026-45342?

LinkAce versions before 2.5.6 fail to enforce data ownership boundaries, allowing any authenticated user to modify colleagues' links, lists, tags, and research materials.. A patch is available.

How to fix or mitigate CVE-2026-45342?

Within 24 hours: Inventory all LinkAce deployments and confirm versions in production. Within 7 days: Upgrade all affected instances to LinkAce 2.5.6 or later. Within 30 days: Audit modification logs from vulnerable versions to identify unauthorized changes and notify users whose resources were accessed or altered.

LinkAce CVE-2026-45342

Q: What is the CVSS score of CVE-2026-45342?

CVE-2026-45342 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-33056 HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-05-28 GitHub_M

Authentication Bypass Linkace

7.1

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

May 29, 2026 - 00:00 vuln.today

Patch available

May 28, 2026 - 23:02 EUVD

CVSS changed

May 28, 2026 - 22:22 NVD

7.1 (HIGH)

CVE Published

May 28, 2026 - 20:47 nvd

UNKNOWN (no severity yet)

DescriptionGitHub Advisory

LinkAce is a self-hosted archive to collect website links. Prior to 2.5.6, LinkAce contains an Insecure Direct Object Reference vulnerability in the authorization policy layer that allows any authenticated user to modify resources owned by other users. The affected resource types are links, lists, tags, and notes. Both the web UI and the REST API are vulnerable. The root cause is in the update() methods of all four model policies: LinkPolicy, LinkListPolicy, TagPolicy, and NotePolicy. Each delegates to an access-check method (e.g., userCanAccessLink()) that returns true for any resource with non-private visibility, regardless of who owns it. This means any registered user can edit any public or internal resource across the entire instance. The delete() methods in the same policy files correctly require ownership via $link->user->is($user), which confirms that update was intended to be owner-only. The same flaw exists in the API layer through AuthorizesUserApiActions::userCanUpdateModel(), which mirrors the broken visibility-only check instead of the ownership check used by userCanDeleteModel(). Bulk edit operations via BulkEditController are also affected. This vulnerability is fixed in 2.5.6.

AnalysisAI

Cross-tenant resource tampering in LinkAce before 2.5.6 lets any authenticated user modify links, lists, tags, and notes belonging to other users whenever those resources have non-private visibility. The flaw exists in both the web UI and the REST API because the update() policy checks validate visibility instead of ownership, while delete() correctly enforces ownership. No public exploit identified at time of analysis, but the bug is trivially exploitable by any registered account on a vulnerable instance.

Technical ContextAI

LinkAce is a self-hosted PHP/Laravel application for archiving website links, identified by CPE cpe:2.3:a:kovah:linkace. The root cause is a CWE-639 Authorization Bypass Through User-Controlled Key: the update() methods of LinkPolicy, LinkListPolicy, TagPolicy, and NotePolicy all delegate to helpers such as userCanAccessLink() which return true for any non-private resource regardless of $resource->user. The same broken pattern is mirrored in the API layer via AuthorizesUserApiActions::userCanUpdateModel(), and the BulkEditController inherits the flaw, so bulk operations are similarly unauthorized. The contrast with the correctly-written delete() checks (which use $link->user->is($user)) confirms ownership was the intended invariant.

RemediationAI

Vendor-released patch: upgrade to LinkAce 2.5.6 or later, which corrects the update() and userCanUpdateModel() checks to enforce ownership in line with the delete() checks; see https://github.com/Kovah/LinkAce/security/advisories/GHSA-cj8f-h888-m57m. If immediate upgrade is not possible, the most effective compensating control is to disable public account registration and audit existing accounts so only trusted users remain, since exploitation requires an authenticated session; operators of single-user instances can place the application behind an authenticating reverse proxy or IP allowlist to prevent unknown accounts from existing at all. As an additional stopgap, set all links, lists, tags, and notes to 'private' visibility - the broken check returns true only for non-private resources - but this will break any intentional sharing and is a temporary measure only until 2.5.6 is deployed.