Bisheng’s legacy single sign-on route issues a valid session token for a username supplied by an unauthenticated caller. The flaw, disclosed on October 14 in CERT/CC vulnerability note VU#166125, remains unpatched. Operators of the DataElement LLM application platform need to find installations where POST /user/sso is reachable and disable or restrict that route while keeping the separately fixed cross-user flaws on their upgrade list.
The route can bind a session to an existing user’s profile. It also registers a supplied username when that account is absent; a new account matching the configured administrative username, or the first user on the system, receives super-administrator privileges. That makes the SSO endpoint an account-takeover path, especially on a new installation or one whose administrator name is known.
How the SSO route grants access
The vulnerable sso() function lives in src/backend/bisheng/user/api/user.py. According to CERT/CC, it processes incoming JSON containing a username and issues a JWT without authenticating the caller. The missing checks include signature verification, a shared secret or a network allowlist. The accepted username determines which account the new session represents. The assigned identifier is CVE-2026-96679.
A JWT is the bearer credential Bisheng uses to represent a session. If an unauthenticated request to the old SSO route produces one for somebody else’s account, ordinary authorization checks later in the application are already working with the wrong identity. The automatic-registration branch adds another route to super-administrator access when the new name matches the configured administrator or occupies the first-user slot.
The flaw is still awaiting an official patch. CERT/CC says DataElement/Bisheng did not respond to multiple coordination efforts. Administrators need to restrict or disable POST /user/sso while that patch is pending.
Other users’ workflows and provider accounts
Two more flaws affect people who already have Bisheng accounts. In CVE-2026-96681, version-retrieval endpoints use caller-supplied parameters to fetch flow and workflow versions without checking ownership or permissions. CERT/CC puts the reach plainly: “Any authenticated user can query and read the complete Domain-Specific Language (DSL) configurations belonging to other accounts.” Those configurations can expose another user’s workflow design. The vendor remediated this workflow issue in 3.0.0, according to the note.
The assistant service has a separate access-control failure, CVE-2026-100156. Its prompt auto-optimization endpoints accept an assistant identifier without verifying that the caller owns that assistant. An authenticated user can run inference billed to somebody else’s configured provider account, including OpenAI, Azure or Anthropic, and see that assistant’s tools and workflows. CERT/CC identifies 2.5.0 as the release that fixes this assistant-service flaw. CERT/CC credits Louis Sanchez of Voke Cyber with reporting the vulnerabilities.
Inventory the installed Bisheng release and whether POST /user/sso is enabled and reachable. Check the 2.5.0 assistant and 3.0.0 workflow fixes on the running service; a reachable legacy SSO route remains exposed even after those upgrades.
Restrict the route and verify
First, locate Bisheng instances and map who can reach POST /user/sso: internet clients, internal user networks, application proxies and trusted local integrations. Review the proxy route and application configuration together. CERT/CC advises avoiding BISHENGPRO=true in the environment, disabling or deprecating the legacy endpoint, or enforcing global JWT validation. Where the route must remain for an integration, restrict its network path to loopback or same-origin access as the note recommends. Enforce access at the ingress serving the endpoint and allow only the integration’s authenticated gateway route or local listener.
Then update installations to the applicable fixed releases for the other two flaws: 2.5.0 for the assistant service and 3.0.0 for workflow versions. If the software is behind a gateway, check the deployed application version and the gateway’s effective route rules on the running service. Account for replicas and alternate ingress paths when testing reachability. For shared Bisheng installations, review cross-user workflow access and provider billing from the period before the upgrade.
Check the deployed SSO path
From a client outside the route’s approved access path, verify that POST /user/sso cannot issue a session; the expected result is a network or ingress denial, or a disabled route. Use a controlled account and an authorized test environment for any application-level authentication check, and verify that an unauthenticated caller receives no JWT. Compare the installed releases against the two fixed-version floors. Inspect prior POST /user/sso traffic as exposure evidence; CERT/CC gives no malicious-request fingerprint for distinguishing attacks from legitimate integration calls.
The immediate job is to remove the unpatched session-issuing path from untrusted reach and check the two separate authorization fixes on the actual running service. A successful version rollout and an ingress rule are different observations: verify both where Bisheng handles LLM workflows and provider accounts.