dbcve.org
Cross-site Scripting (XSS)Weakness · CWE-79

CVE-2026-45343

HIGH · 8.5 CVSS v4.0 Published 2026-05-28
Mitigation only
No fix yet — a mitigation exists. There is no fixed release. A documented workaround reduces exposure in the meantime.
See remediation →
89/100
Remediation priority · High
Remotely reachable

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
LinkAce is a self-hosted archive to collect website links. Prior to 2.5.6, LinkAce contains a stored cross-site scripting vulnerability that allows a low-privilege user to execute arbitrary JavaScript in an administrator's browser session. This affects instances configured with SSO/OAuth authentication, which is one of the supported authentication methods in LinkAce. An attacker who sets their OAuth display name to a malicious script and then creates an API token will plant a persistent XSS payload in the audit log. When any admin navigates to /system/audit, the payload executes in the admin's browser context. This enables session cookie theft, CSRF token exfiltration (exposed in the la-app-data meta tag), or any other action the admin can perform. This vulnerability is fixed in 2.5.6.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A stored XSS vulnerability in LinkAce versions prior to 2.5.6 allows low-privilege users to inject malicious JavaScript via their OAuth display name. When these users create an API token, the malicious payload is persisted in the audit log. When administrators access /system/audit, the payload executes in their browser context, enabling session cookie theft and CSRF token exfiltration.

MitigationUpgrade LinkAce to version 2.5.6 or later. After upgrading, review audit logs for any suspicious entries and consider rotating sessions/tokens as a precaution.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
Authentication
X
User interaction
P
Scope
X

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify LinkAce installation and version
    Check the installed LinkAce version by reviewing the application files, composer.json, or the admin interface. Common locations include the root directory composer.json file or the application footer in the web UI.
    Affected if The installed version is prior to 2.5.6 (versions 2.5.5, 2.5.0, earlier releases).
  2. Determine if OAuth/SSO authentication is enabled
    Review the LinkAce configuration files (typically in config/ or .env) for OAuth provider settings such as OAUTH_, SOCIALITE_, or SSO-related environment variables. Alternatively, check the authentication settings in the admin panel.
    Affected if OAuth/SSO authentication is enabled and users can authenticate through external providers.
  3. Identify low-privilege users with OAuth-linked accounts
    Query the users table in the database for accounts with OAuth provider associations. Look for users with non-admin roles who have provider_type or provider_id fields populated, indicating OAuth/SSO login.
    Affected if There are non-administrative users who authenticated via OAuth/SSO providers.
  4. Examine the audit log for suspicious entries
    Navigate to /system/audit in the web interface or query the audit_logs database table. Review entries related to API token creation (look for action types like 'api_token_created' or 'api_token_added').
    Affected if The audit log contains entries with display names or user identifiers containing HTML/JavaScript content from OAuth providers.
  5. Inspect page source for XSS execution context
    As an administrator, view the audit log at /system/audit and inspect the browser page source. Search for the la-app-data meta tag and any embedded script tags or event handlers in user-displayed fields.
    Affected if User-supplied data from OAuth display names appears unmodified in the audit log HTML output, allowing script execution.

A user is affected if they run LinkAce version prior to 2.5.6 with OAuth/SSO enabled and the audit log contains unsanitized OAuth display names from API token creation events.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Mitigation available No clean upgrade yet — mitigate in the meantime
Mitigation

Upgrade LinkAce to version 2.5.6 or later. After upgrading, review audit logs for any suspicious entries and consider rotating sessions/tokens as a precaution.

Recommended fix High confidence

2.5.6

  1. 1. Back up your current LinkAce installation and database before proceeding with any upgrade.
  2. 2. Navigate to your LinkAce server's terminal/shell.
  3. 3. Pull the latest version using your deployment method (e.g., Docker pull, git fetch, or composer update).
  4. 4. Ensure you upgrade to version 2.5.6 or later which contains the security fix.
  5. 5. If using Docker, update your image tag to the fixed version and recreate containers: `docker-compose up -d`
  6. 6. If using manual installation, run migration commands as needed for your setup.
  7. 7. Verify the upgrade was successful by checking the LinkAce version in the admin interface.
  8. 8. After upgrade, review audit log entries from untrusted OAuth users and remove any malicious entries if present.

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation2.0 h
  • Implementation2.0 h
  • Testing2.0 h
  • Review / QA1.0 h
7.0 hours of engineering $1,240
Get help mitigating

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,984.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-45343 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-45343 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data