# 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?)

**URL:** <https://discuss.elastic.co/t/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/391220>\
**Category:** Kibana\
**Tags:** elastic-stack-security\
**Created:** [October 27, 2026, 10:10am UTC](https://discuss.elastic.co/t/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/391220 "2026-10-27T10:10:41Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![midou\_dev](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/midou_dev/32/148472_2.png) [@midou\_dev](https://discuss.elastic.co/u/midou_dev)\
**Post date:** [October 27, 2026, 10:10am UTC](https://discuss.elastic.co/t/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/391220/1 "2026-10-27T10:10:41Z")

</div>

**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**

```auto
[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:

```auto
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:

```auto
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?