---
id: 2026-10-bisheng-llm-platform-unpatched-sso-admin-jwt-cve-cluster-cert-cc
title: "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"
date_disclosed: 2026-10-14
last_updated: 2026-10-14
severity: critical
status: active
ecosystems: [llm-platform, ai-agents, python, docker]
tools_affected: ["Bisheng (DataElement) all released versions for CVE-2026-96679, no fix", "Bisheng before 3.0.0 (CVE-2026-96681, per CERT/CC; no 3.0.0 release exists yet)", "Bisheng before 2.5.0 (CVE-2026-100156)", "Bisheng before 2.6.0 (CVE-2026-82278, Code node still unsandboxed)", "Bisheng through 2.6.0-fix2 (CVE-2026-82285)", "Bisheng 2.3.0, 2.4.0, 2.4.0-beta1 (CVE-2026-51859, CVE-2026-51860, CVE-2026-51861)"]
tags: [cve, cert-cc, llm-platform, auth-bypass, sso, jwt, account-takeover, idor, rce, exec, ssrf, path-traversal, unresponsive-vendor, no-fix, active]
---

## 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](2026-09-ro1me-open-source-agent-framework-llm-output-execution-cve-wave.md) 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?

```bash
# 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](../playbooks/rotating-cloud-credentials.md)), 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](../playbooks/if-your-webapp-was-compromised.md).

## 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](../prevention/credential-hygiene.md).
- Run the platform's Code node, if at all, in a sandbox you control; [agent-sandboxing](../prevention/agent-sandboxing.md).
- 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
- [CERT/CC — VU#166125: Bisheng has authentication bypass vulnerabilities](https://kb.cert.org/vuls/id/166125) (published 2026-10-14; CVE-2026-96679, CVE-2026-96681, CVE-2026-100156; vendor notified 2026-08-06, no response; mitigations; reporter Louis Sanchez, Voke Cyber)
- [VulnCheck — Bisheng authenticated arbitrary Python code execution via workflow run_once](https://www.vulncheck.com/advisories/bisheng-authenticated-arbitrary-python-code-execution-via-workflow-run-once) (2026-08-28, CVE-2026-82278, before 2.6.0, CVSS 8.7, credit George Chen)
- [GitHub Advisory Database — GHSA-h3mc-9q4p-46jg (CVE-2026-82278)](https://github.com/advisories/GHSA-h3mc-9q4p-46jg), [GHSA-qch5-28r4-f5gj (CVE-2026-82285)](https://github.com/advisories/GHSA-qch5-28r4-f5gj), [GHSA-vx7w-p635-5ppx (CVE-2026-51859)](https://github.com/advisories/GHSA-vx7w-p635-5ppx), [GHSA-9227-j4qr-f6gf (CVE-2026-51860)](https://github.com/advisories/GHSA-9227-j4qr-f6gf), [GHSA-4w4g-gc64-8m74 (CVE-2026-51861)](https://github.com/advisories/GHSA-4w4g-gc64-8m74) (descriptions, vectors, references; all unreviewed, no package metadata)
- [dataelement/bisheng — issue #2189: Authenticated RCE via run_once endpoint](https://github.com/dataelement/bisheng/issues/2189) (opened 2026-07-03 by geo-chen; maintainer reply 2026-09-22 listing what was fixed, the unsandboxed Code node, the default-off switch on 3.0.0-beta2; closed 2026-09-29)
- [dataelement/bisheng — releases](https://github.com/dataelement/bisheng/releases) (v3.0.0-beta4 2026-10-13 newest; V3.0.0-beta3 2026-10-09 "fixed multiple security vulnerabilities", open API previously unauthenticated; v2.6.0-fix2 2026-08-11 last 2.x; no 3.0.0 or 2.5.0 fix note visible on the first page)
- [dataelement/bisheng — security advisories tab](https://github.com/dataelement/bisheng/security/advisories) (empty on 2026-10-14)
- CVE Services returned no record for CVE-2026-96679, CVE-2026-96681 or CVE-2026-100156 on 2026-10-14; the ids are cited from the CERT/CC note