Bisheng LLM platform: unauthenticated SSO endpoint mints admin JWTs with no fix (CVE-2026-96679), plus seven CVEs since August; vendor silent to CERT/CC

View raw markdownEdit on GitHub ↗

TL;DR

Bisheng, DataElement's open-source LLM application platform (the Langflow and Dify class: workflows, assistants, a Code node, stored provider keys), has an unauthenticated account takeover with no fix. CERT/CC published VU#166125 on 2026-10-14: the legacy SSO endpoint POST /user/sso issues a JWT without verifying the caller, creates unknown accounts on the fly, and makes an account whose name matches the admin username or the first user a super-admin (CVE-2026-96679, not patched; the vendor "has not responded to multiple coordination efforts" since notification on 2026-08-06). The same note carries two authenticated flaws the vendor did fix: cross-user read of flow and workflow DSL (CVE-2026-96681, "3.0.0") and assistant prompt auto-optimisation that runs inferences billed to another user's OpenAI, Azure or Anthropic account (CVE-2026-100156, 2.5.0). Five more Bisheng CVEs reached the advisory database in August and September with no file here: authenticated Python exec() through the workflow run_once endpoint (CVE-2026-82278, 8.7, ownership check fixed, sandbox not), unauthenticated SSRF through the report callback (CVE-2026-82285, 8.8, through 2.6.0-fix2) and three path and code injections in 2.3.0 to 2.4.0 (CVE-2026-51859, CVE-2026-51860, CVE-2026-51861, up to 9.8). Do not expose a Bisheng instance; set BISHENG_PRO off and block /user/sso at the proxy until a fix exists.

What happened

The CERT/CC note (2026-10-14)

Reporter: Louis Sanchez, Voke Cyber. Vendor notified 2026-08-06; note published and last revised 2026-10-14; every vendor status "Unknown", no vendor statement received.

CVE Flaw Fixed in Impact
CVE-2026-96679 POST /user/sso issues JWTs without verifying the caller, auto-creates unknown accounts, and promotes an account matching the admin username or the first user to super-admin not patched unauthenticated account takeover up to super-admin, full application compromise
CVE-2026-96681 flow and workflow version endpoints do not check ownership 3.0.0 per CERT/CC any authenticated user reads other accounts' DSL configurations
CVE-2026-100156 assistant prompt auto-optimisation does not verify the caller owns the assistant ID 2.5.0 authenticated user runs inferences on a victim's provider account and reads the assistant's tools and workflows

CERT/CC's interim mitigations for the SSO flaw: do not set BISHENG_PRO=true; disable the legacy SSO endpoint or enforce global JWT validation (the function is sso() in src/backend/bisheng/user/api/user.py); restrict POST /user/sso to loopback or same-origin requests.

Two version notes the note's wording needs. CVE Services had no record for CVE-2026-96679, CVE-2026-96681 or CVE-2026-100156 on 2026-10-14; the ids are printed on the CERT/CC note and nowhere else yet. And CERT/CC's "fixed in 3.0.0" names a version the repository has not released: the releases page tops out at v3.0.0-beta4 (2026-10-13), after V3.0.0-beta3 (2026-10-09), whose notes say the open API "previously had no authentication" and that the release "fixed multiple security vulnerabilities" without naming them. Whether a beta carries the ownership fix is unstated, so no "upgrade to" line is derived from it here.

The five earlier records

None of these had a file in this corpus; the product had never been grepped. They are listed because an operator reading the CERT/CC note needs the whole exposure, and because the maintainer's one public reply (below) is the only vendor signal for any of the eight.

  • CVE-2026-82278 (VulnCheck CNA, 2026-08-28, CVSS 4.0 8.7, credit George Chen): any authenticated user submits a crafted Code node definition to POST /api/v1/workflow/run_once and the server runs it with Python exec(), no sandbox, with the backend's filesystem, credentials and network. Affected before 2.6.0. The reporter's issue #2189 (opened 2026-07-03, after a private advisory filed 2026-06-01 went unanswered) got a maintainer reply on 2026-09-22: the missing ownership check on run_once is fixed, workflow and assistant creation now require app-creation permission, the hardcoded JWT secret is replaced by configuration with the two historical defaults rejected, the shipped compose file no longer carries default MinIO credentials, and the Code node sandbox is not fixed: user Python still runs through exec() as the backend process, a sandbox is "in development", and a default-off switch to disable the Code node ships on the 3.0.0-beta2 line (commit 33bdf8a). The maintainer's own guidance is to keep the Code node disabled until the sandbox lands, because any user who can create or edit a workflow can run commands on the server. The issue was closed as completed on 2026-09-29.
  • CVE-2026-82285 (VulnCheck CNA, 2026-08-28, CVSS 4.0 8.8): POST /api/v1/workflow/report/callback has no authentication, no URL scheme restriction and no host filtering, so an unauthenticated caller makes the server fetch internal services and cloud metadata endpoints and then reads the captured responses back out of object storage by object name. Affected through 2.6.0-fix2; no fix on record.
  • CVE-2026-51859 (NVD, 2026-09-30, CVSS 3.1 9.1), CVE-2026-51860 (7.5) and CVE-2026-51861 (9.8): directory traversal in save_download_file, directory traversal in the Linsight task executor, and code injection in api/v1/validate.py, each for versions 2.3.0, 2.4.0 and 2.4.0-beta1, each from one reporter's (Ro1ME) issues #1994 and #1995 with no affected-package metadata and no fix on record. These are the Ro1ME wave shape: a MITRE id for an unanswered issue, scored for the worst case.

Together: an unauthenticated path to super-admin (SSO), an unauthenticated SSRF (callback), and from any account an unsandboxed exec() (Code node) that the vendor's own fix leaves on by default. The provider keys the platform stores are the reason the audience should care; CVE-2026-100156 shows what one authenticated user can already do with another's.

Am I affected?

# Deployed version: the backend image tag, or the version string on the login page
docker ps --format '{{.Image}}' | grep -i bisheng

# Is the legacy SSO endpoint reachable from where an attacker stands? Check your proxy
# rules for /user/sso; an instance reachable from the internet with BISHENG_PRO=true is
# the exposed configuration CERT/CC describes.
grep -r 'BISHENG_PRO' .env docker-compose*.yml 2>/dev/null

# Accounts you did not create, and accounts named like the admin user: list users in the
# admin console (or query the platform's user table directly) ordered by creation time, newest first.

For the exec() record, every workflow saved by an account you do not fully trust is a possible command run; the maintainer's guidance is to disable the Code node, and the switch exists only on the 3.0.0 beta line.

If you are affected

Take the instance off the internet. Block POST /user/sso at the proxy, set BISHENG_PRO off, rotate every provider key and every credential stored in the platform (rotating cloud credentials), and audit the user table and the workflow list for entries you did not make. If the Code node was enabled for untrusted users, treat the backend host as compromised: if your webapp was compromised.

Prevention

  • An LLM platform that stores provider keys and runs user code is an admin tool, not a shared app; put it behind your identity provider and never on a public address. credential-hygiene.
  • Run the platform's Code node, if at all, in a sandbox you control; agent-sandboxing.
  • Before adopting an open-source agent platform, read its security tab and its open issues labelled security. Bisheng's tab is empty while eight CVEs exist; the issues are where the maintainer answered.

Sources