Safeguard
Vulnerability Analysis•

CVE-2026-110215: High Missing Authorization in youlai-boot

CVE-2026-110215 lets any logged in youlai-boot user grant their own role every permission. Affects 2.21.1 and earlier. Apply the linked fix commit.

Safeguard Security Team
Updated 4 min read

CVE-2026-110215 is a High severity (CVSS 8.8) missing authorization flaw in youlai-boot through 2.21.1. A low-privileged user can assign any menu and button permissions to roles, including their own. We could not confirm a fixed release, so check the project commit and apply it.

What's affected

The record says youlai-boot through 2.21.1 is affected. It links a commit in the project repository, and a researcher write-up, but we did not find a release note that names a fixed version. Treat the commit as the project's fix and confirm which release carries it before you plan an upgrade.

The weakness is CWE-862, missing authorization. The record describes the role menu assignment endpoint, a PUT request under /api/v1/roles. It does not check that the caller may change role permissions. The record gives the example of the built in guest test account. A user can send the request for their own role, the permission cache in Redis is refreshed, and the account then has administrator-equivalent access.

Severity differs by source. The record gives 8.8 (High) and VulnCheck lists 8.7 (High). Both are High.

How to check if you're exposed

Find out which youlai-boot version you deploy. Look at the version in your build file.

grep -n "<version>" pom.xml | head -5

If the project version is 2.21.1 or lower, you are in range, unless you have already applied the fix commit. Next, check whether the default test accounts are still enabled in any shared environment. Demo and test users with weak passwords turn this from an insider issue into an exposed one.

Review the role and menu tables for permission grants you do not recognise, and check the audit trail for calls to the role menu endpoint made by non-admin accounts. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.

What to do now

  1. Apply the project's fix from the linked commit, or upgrade to a release that contains it once you have confirmed which one that is.
  2. Disable or remove default test accounts, including the guest account, in every environment that is reachable from a network.
  3. Add a server side permission check on the role menu endpoint so only administrators can call it, if you maintain a fork.
  4. Review roles and menu assignments, and compare them to a known good backup.
  5. Clear the Redis permission cache after you correct roles so stale grants do not remain.

Why it matters

Role based access control fails when the page that edits roles is not itself protected. If any logged in user can edit a role, the permission model is decorative. This pattern is a close relative of broken access control, the top category in many web application risk lists.

The advisory style write-ups for flaws like this one often come from source code review, not from incident reports. Nothing in the record says this is exploited. Still, a single request that lifts a guest to administrator is a cheap win for anyone who finds a reachable instance. The record does not mark this CVE as known exploited, and none of the pages we read say it is.

Quick check

Which youlai-boot version is fixed?

We could not confirm one. The record links a fix commit, so check which release includes it.

What does an attacker need?

An authenticated account of any privilege level, such as the guest test account the record mentions.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.