What is the CVSS score of CVE-2026-50561?

CVE-2026-50561 has a CVSS 3.1 base score of 9.4 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L. EPSS exploitation probability: 0.4%.

Which versions of Yuxi are affected by CVE-2026-50561?

Yuxi versions prior to 0.6.2 contain a critical authentication bypass that allows attackers to assume administrator privileges without valid credentials, resulting in complete backend compromise.. A patch is available.

How to fix or mitigate CVE-2026-50561?

Within 24 hours: Verify whether your Yuxi deployment uses the default secret 'yuxi_know_secure_key' and audit recent admin token usage for anomalies indicating unauthorized access. Within 7 days: Immediately upgrade all Yuxi instances to version 0.6.2, then invalidate all existing admin sessions to revoke forged tokens. Within 30 days: Conduct forensic analysis of logs and database changes during the exposure window to detect any unauthorized modifications, and implement continuous monitoring for anomalous JWT signing patterns.

Yuxi CVE-2026-50561

EUVD-2026-57220 CRITICAL

Improper Authentication (CWE-287)

2026-08-12 GitHub_M

Authentication Bypass Yuxi

9.4

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.4 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

vuln.today AI

9.8 CRITICAL

Remote reach plus a publicly known default secret gives AC:L/PR:N; admin access exposes configs (C:H), enables management-API abuse (I:H) and full backend takeover including disruption (A:H).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

Low

Lifecycle Timeline

Patch available

Aug 12, 2026 - 15:02 EUVD

Source Code Evidence Fetched

Aug 12, 2026 - 14:52 vuln.today

Analysis Generated

Aug 12, 2026 - 14:52 vuln.today

CVE Published

Aug 12, 2026 - 14:07 cve.org

CRITICAL 9.4

DescriptionCVE.org

Yuxi is a large-model-based intelligent knowledge base and knowledge graph agent development platform. Prior to version 0.6.2, the project's authentication mechanism contains a flaw. In affected versions, the system does not sufficiently validate the identity token in the Authorization header - only performing a validity check. This allows an administrator token generated in another deployment instance or local testing environment to be used to access the backend management interfaces of a different affected instance. An attacker who obtains or constructs an acceptable administrator Authorization token may bypass normal login authentication and gain administrator privileges. This vulnerability could allow an attacker to access system configurations, invoke backend management APIs, create administrator accounts, and ultimately take over the system backend. This issue has been fixed in version 0.6.2. Before upgrading, users are advised to implement the following temporary measures: Set the environment variable JWT_SECRET_KEY to a non-default value, and configure a unique, sufficiently strong JWT/authentication key for each deployment instance; and/or avoid exposing backend management interfaces directly to the public network.

AnalysisAI

Administrator authentication bypass in Yuxi (xerrors/Yuxi), a large-model-based knowledge base and knowledge-graph agent platform, affects all versions prior to 0.6.2. Because the backend only checks that a JWT is validly signed - without binding it to the specific deployment instance - an admin token minted in any other Yuxi instance, a local test environment, or one forged with the hardcoded default secret 'yuxi_know_secure_key' is accepted as a valid administrator, yielding full backend takeover. There is no public exploit identified at time of analysis, but the fix commit and the hardcoded default key are publicly visible on GitHub, making token forgery trivial wherever the secret was never changed.

Technical ContextAI

The affected component is Yuxi's FastAPI/SQLAlchemy backend authentication layer (backend/server/utils/auth_utils.py and auth_middleware.py). The root cause is CWE-287 (Improper Authentication): token creation and verification used a single symmetric HS256 JWT secret read from JWT_SECRET_KEY with a hardcoded fallback of 'yuxi_know_secure_key', and verification checked only signature validity and expiry - it did not enforce an issuer (iss) or audience (aud) claim, so tokens were not tied to a particular deployment. Any instance sharing (or defaulting to) the same secret therefore trusts each other's tokens. The 0.6.2 fix rejects the legacy default key, auto-generates per-instance JWT_SECRET_KEY and YUXI_INSTANCE_ID values, and now requires and validates iss/aud claims (JWT_AUDIENCE 'yuxi-know-api', issuer 'yuxi-know:<instance_id>'), while also adding rejection of deleted and login-locked users' tokens. CPE cpe:2.3:a:xerrors:yuxi identifies the single affected product.

RemediationAI

Vendor-released patch: 0.6.2 - upgrade to Yuxi 0.6.2, which rejects the legacy default JWT secret, generates a unique per-instance JWT_SECRET_KEY and YUXI_INSTANCE_ID, and enforces issuer/audience claims so tokens can no longer be reused across instances (see GHSA-6959-99pq-c56x and commit 1e8b20e30b1258d1cd3ebf3af5c6212da4b84b48). If immediate upgrade is not possible, set the environment variable JWT_SECRET_KEY to a non-default, unique, strong random value for each deployment instance (never leave it at the default 'yuxi_know_secure_key'), which invalidates cross-instance and default-secret forged tokens but will invalidate existing sessions signed with the old key; and/or avoid exposing the backend management interfaces directly to the public network by placing them behind a VPN, IP allowlist, or authenticating reverse proxy, at the cost of reduced remote administrative convenience.