Kibana 9.5.5 basic login fails ~50% of the time: “no handler found” when creating session document in .kibana_security_session (unencoded / in session ID?)

Elastic Stack Kibana
1

Environment

  • Kibana 9.5.5
  • Elasticsearch 9.5.5, 3 nodes
  • Authentication: basic provider (username/password)

Problem

When logging in to Kibana with basic authentication, the login form often shows “Username or password is incorrect. Please try again.” Clicking Login again once or twice eventually works. The credentials are correct.

Kibana logs on a failed login

[ERROR][plugins.security.session.index] Failed to create session value:
{"error":"no handler found for uri [/.kibana_security_session/_create/+sh/<REDACTED>=?refresh=false&require_alias=true] and method [PUT]"}

[ERROR][plugins.security.authentication] Login attempt with "basic" provider failed due to unexpected error:
{"error":"no handler found for uri [/.kibana_security_session/_create/+sh/<REDACTED>=?refresh=false&require_alias=true] and method [PUT]"}

[ERROR][http] 500 Server Error  (POST /internal/security/login)

Stack trace:

ResponseError: {"error":"no handler found for uri [...] and method [PUT]"}
  at ClientTraced.CreateApi [as create] (@elastic/elasticsearch/lib/api/api/create.js)
  at SessionIndex.writeNewSessionDocument (@kbn/security-plugin/server/session_management/session_index.js)
  at SessionIndex.create (...)
  at Session.create (...)
  at Authenticator.updateSessionValue (...)
  at Authenticator.login (...)

On a successful attempt, the logs show only Login attempt with "basic" provider succeeded.

What I found

The session ID used as the document _id is a base64 string (44 characters, standard alphabet, so it can contain +, / and =). In every failed attempt I checked, the ID contains a /, and the URL sent to Elasticsearch contains it unencoded:

PUT /.kibana_security_session/_create/+sh/<rest of ID>=?refresh=false&require_alias=true

Elasticsearch then sees an extra path segment and returns no handler found for uri. Since a 44-character base64 ID contains at least one / roughly half the time, this matches the ~50% failure rate.

Tests done directly against Elasticsearch (127.0.0.1:9200, user kibana_system)

  • PUT /.kibana_security_session/_create/test+sh/abc=?refresh=false&require_alias=true → no handler found for uri on all 3 nodes (raw / in the ID).
  • PUT /.kibana_security_session/_create/test-abc123?refresh=false&require_alias=true → 201 created (ID without /). The same works through the VIP.
  • PUT .../_create/test%2Fabc direct on a node: <result to fill in>
  • PUT .../_create/test%2Fabc2 through the VIP: <result to fill in>

So the alias, the privileges of kibana_system and the _create API work correctly. The failure only occurs when the ID contains a raw /.

Questions

  1. Is Kibana 9.5.5 expected to URL-encode the session ID (e.g. %2F) when calling the create API? From the log it appears to be sent raw.
  2. If Kibana does send %2F, could the VIP/proxy be decoding it before it reaches Elasticsearch? (I’m checking this.)
  3. Is this a known issue, and is there a fixed version or workaround?