bug: Databend HTTP Client Session State Key Collision

[3em0]

Search before asking

• I had searched in the issues and found no similar issues.

Version

Observed on main at commit 21377cd76bb1e84f92bfc9da1acc881b8841f1de (2026-03-24, fix(query): escape LIKE ESCAPE literals in display (#19596)).

What's Wrong?

ClientSessionManager stores and restores HTTP temporary-table session state under a key that is not tenant-scoped. This can cause cross-tenant session state confusion when two tenants have the same user name and the same client session id.

Relevant code path:

• src/query/service/src/sessions/session.rs:449 builds the temporary table prefix for HTTP sessions as format!("{user}/{client_session_id}").
• src/query/sql/src/planner/binder/ddl/table.rs:691 stores that prefix in OPT_KEY_TEMP_PREFIX for temporary tables.
• src/query/service/src/interpreters/interpreter_table_create.rs:195 and :373 register temporary table state with ClientSessionManager.
• src/query/service/src/servers/http/v1/session/client_session_manager.rs:99 builds the in-memory session state key as format!("{user_name}/{client_session_id}").
• src/query/service/src/servers/http/v1/session/client_session_manager.rs:402 restores the temp-table manager from this key on query start.
• src/query/service/src/servers/http/middleware/session.rs:412 allows X-DATABEND-TENANT to set the tenant before authentication.
• src/query/service/src/servers/http/middleware/session_header.rs:140 accepts a client-provided X-DATABEND-SESSION when X-DATABEND-CLIENT-CAPS: session_header is enabled.

Because tenant identity is omitted from both the temporary table prefix and the in-memory session state key, these two different authenticated contexts map to the same server-side state entry:

tenant=tenant_alpha, user=analyst, client_session_id=018f2b74-0000-7000-8000-000000000001
tenant=tenant_beta,  user=analyst, client_session_id=018f2b74-0000-7000-8000-000000000001

state key for both: analyst/018f2b74-0000-7000-8000-000000000001

The likely impact is cross-tenant temporary table state confusion on the same query node while the state is resident in memory. Depending on table contents and query flow, this can expose or reuse temporary table metadata/data across tenants.

The expected behavior is that tenant identity should be included in the session state namespace, for example tenant/user/client_session_id, and the same tenant-scoped key should be used consistently for temporary table prefixing, registration, restore, refresh, and cleanup.

How to Reproduce?

I verified the collision locally with synthetic values only; no production system or real user data was accessed.

Minimal model-level reproduction:

state_key(client_session_id, user_name) = "{user_name}/{client_session_id}"

A:
  tenant: tenant_alpha
  user: analyst
  client_session_id: 018f2b74-0000-7000-8000-000000000001
  state_key: analyst/018f2b74-0000-7000-8000-000000000001
  temporary table marker: alpha_sensitive_tmp

B:
  tenant: tenant_beta
  user: analyst
  client_session_id: 018f2b74-0000-7000-8000-000000000001
  state_key: analyst/018f2b74-0000-7000-8000-000000000001
  temporary table marker: beta_session

Observed:
  state_key(A) == state_key(B): true
  tenant(A) != tenant(B): true
  B's key resolves to A's stored temporary table state.

I saved the local verification note as agentscan_session_key_verification.md in the repository root.

Suggested fix:

Include tenant in the temporary table/session state key, and use the tenant-scoped value everywhere the current user/session prefix is produced or consumed.

Are you willing to submit PR?

• Yes I am willing to submit a PR!