# Elasticsearch Kibana 9.4.0 Basic authentication returns 401 Unauthorized

**URL:** <https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318>\
**Category:** Kibana\
**Created:** [May 13, 2026, 9:02am UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318 "2026-05-13T09:02:22Z")\
**Posts on this page:** 18\
**Page:** 2

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 19, 2026, 2:54pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/21 "2026-05-19T14:54:56Z")

</div>

> [@RainTown](#):
>
> I guess there might be some additional debug or trace-level logging enable-able in kibana that might also help, but sadly I dont know which specific setting might help.

FYI I added

```auto
logging.loggers:
  - name: security
    level: trace
  - name: plugins.security
    level: trace

```

to my kibana.yml and get some more diagnostics.

This includes somewhat confusing message like this set for a successful (httpCode 200) curl call to `/api/features` with the `-H 'Authorization: Basic xxxxx' header:

```auto
DEBUG plugins.security.basic.basic 2026-05-19T16:47:04.147+02:00 Trying to authenticate user request to /api/features.
DEBUG plugins.security.basic.basic 2026-05-19T16:47:04.147+02:00 Cannot authenticate requests with `Authorization` header.
DEBUG plugins.security.http 2026-05-19T16:47:04.147+02:00 Trying to authenticate user request to /api/features.
DEBUG plugins.security.http 2026-05-19T16:47:04.149+02:00 "Request to /api/features has been authenticated via authorization header with ""Basic"" scheme."

```

---

<div class="post-metadata">

**Author:** ![GeertVerbeurgt](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@GeertVerbeurgt](https://discuss.elastic.co/u/GeertVerbeurgt)\
**Post date:** [May 20, 2026, 1:30pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/22 "2026-05-20T13:30:24Z")

</div>

I did a fresh single node installation of version 9.3.0 and version 9.4.0 with minimal configuration

`9.3.0 no problem`

`9.4.0 -> authentication error for Kibana`

Installation files :

```auto
elasticsearch-9.3.0-linux-x86_64.tar.gz
kibana-9.3.0-linux-x86_64.tar.gz

```

```auto
elasticsearch-9.4.0-linux-x86_64.tar.gz
kibana-9.4.0-linux-x86_64.tar.gz

```

Users :

- testuser

```auto
./elasticsearch-users useradd testuser -p testpassword -r superuser

```

```auto
echo -n 'testuser:testpassword' | base64
dGVzdHVzZXI6dGVzdHBhc3N3b3Jk

```

- accessuser ( used for connection between kibana and elasticsearch )

```auto
./elasticsearch-users useradd accessuser -p accesspassword -r kibana_system

```

```auto
echo -n 'accessuser:accesspassword' | base64
YWNjZXNzdXNlcjphY2Nlc3NwYXNzd29yZA==

```

Elasticsearch configuration :

elasticsearch.yml

```auto
cluster.name: my-application-cluster
node.name: node-1
network.host: localhost
discovery.type: single-node

xpack.security.enabled: false
xpack.security.enrollment.enabled: false
xpack.security.http.ssl.enabled: false
xpack.security.transport.ssl.enabled: false

```

users :

```auto
testuser:$2a$10$Ovv7PFp9yIqNUxjA0saJdeYhbvRnG1WQjtq5.RQ9SD0LxenDk/Ppm
accessuser:$2a$10$qYcpf4o/syrmcsKLrZsk/uBlhtML7/OQPcKLr2Ynyo0N2uqqQZldq

```

users\_roles :

```auto
kibana_system:accessuser
superuser:testuser

```

Kibana configuration :

kibana.yml :

```auto
server.port: 8100
server.host: "127.0.0.1"
server.ssl.enabled: false

elasticsearch.hosts: "http://127.0.0.1:9200"
elasticsearch.username: accessuser
elasticsearch.password: accesspassword

```

Curl cmd used to test with 'testuser' :

```auto
curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:9200/_cat/indices

curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:8100/api/spaces/space

curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:8100/app/id/any*

```

- [http://127.0.0.1:9200/\_cat/indices](http://127.0.0.1:9200/_cat/indices) for version 9.3.0 after starting Kibana

```auto
green open .internal.alerts-transform.health.alerts-default-000001 NUkXE6vMTbaCEANgUQxQPQ 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.logs.alerts-default-000001 Vw0qWTh7S72oJP9-5xqeQg 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.uptime.alerts-default-000001 efx5KZIGRvmrilwdefxocg 1 0 0 0 227b 227b 227b
green open .internal.alerts-ml.anomaly-detection.alerts-default-000001 2ptaNeEoQqKChdRP7hdX7Q 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.slo.alerts-default-000001 cdkCrLY3TDWxcXkVThC1xw 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.apm.alerts-default-000001 DnfCvTRIRpqhkDkJFa-mQw 1 0 0 0 227b 227b 227b
green open .internal.alerts-default.alerts-default-000001 2RLWLTDrQye5t-exyGCsGw 1 0 0 0 227b 227b 227b
green open .internal.alerts-streams.alerts-default-000001 9dc4P_q5TfOUwdponGkxTA 1 0 0 0 227b 227b 227b
green open .internal.alerts-security.attack.discovery.alerts-default-000001 HNNsk85oQXGLT6nMsN7C1Q 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.metrics.alerts-default-000001 gdbgaMm4QUqgh7o9kroSkw 1 0 0 0 227b 227b 227b
green open .internal.alerts-observability.threshold.alerts-default-000001 U5trAxppTVW57UxSIuNPfg 1 0 0 0 227b 227b 227b
green open .internal.alerts-ml.anomaly-detection-health.alerts-default-000001 LNRgcuSLS5SzUe2aCQNa7A 1 0 0 0 227b 227b 227b
green open .internal.alerts-security.alerts-default-000001 9q3_w46OSw2vNTlpTmqNCg 1 0 0 0 227b 227b 227b
green open .internal.alerts-dataset.quality.alerts-default-000001 j_eM8jHGRlWIF3UEIXDqIQ 1 0 0 0 227b 227b 227b
green open .internal.alerts-stack.alerts-default-000001 Zz1L5bgHTpawesknNVOQsA 1 0 0 0 227b 227b 227b

```

- [http://127.0.0.1:9200/\_cat/indices](http://127.0.0.1:9200/_cat/indices) for version 9.4.0 after starting Kibana ( only 1 )

```auto
green open .internal.alerts-security.alerts-default-000001 x1rd8iDKRtqu-zEASRP4jw 1 0 0 0 249b 249b 249b

```

- [http://127.0.0.1:8100/api/spaces/space](http://127.0.0.1:8100/api/spaces/space) for version 9.3.0 and 9.4.0 -\> `HTTP/1.1 200 OK`

- [http://127.0.0.1:8100/app/id/any\\](http://127.0.0.1:8100/app/id/any%5C%5C)\* for version 9.3.0 -\> `HTTP/1.1 200 OK`

- [http://127.0.0.1:8100/app/id/any\\](http://127.0.0.1:8100/app/id/any%5C%5C)\* for version 9.4.0

```auto
[2026-05-20T14:47:39.185+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
[2026-05-20T14:47:43.729+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
[2026-05-20T14:47:43.767+02:00][DEBUG][plugins.security.user-profile] Request to get current user profile is authenticated via Basic credentials.
[2026-05-20T14:47:43.768+02:00][DEBUG][plugins.security.user-profile] Activating user profile via password grant.
[2026-05-20T14:47:43.781+02:00][ERROR][plugins.security.user-profile] Failed to activate user profile: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}.
[2026-05-20T14:47:43.782+02:00][DEBUG][plugins.security.user-profile] Failed to activate profile via basic credentials: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}
[2026-05-20T14:47:43.783+02:00][ERROR][http] 500 Server Error

```

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [May 20, 2026, 2:24pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/23 "2026-05-20T14:24:09Z")

</div>

Hi @GeertVerbeurgt  
Thank you for the detail  
But Sorry Which user / role are you using for each curl ... it is not clear  
I am looking.... trying to reproduce

> [@GeertVerbeurgt](#):
>
> - [http://127.0.0.1:9200/\_cat/indices](http://127.0.0.1:9200/_cat/indices) for version 9.4.0 after starting Kibana ( only 1 )
> 
> ```auto
> green open .internal.alerts-security.alerts-default-000001 x1rd8iDKRtqu-zEASRP4jw 1 0 0 0 249b 249b 249b
> 
> ```
> 
> - [http://127.0.0.1:8100/api/spaces/space](http://127.0.0.1:8100/api/spaces/space) for version 9.3.0 and 9.4.0 -\> `HTTP/1.1 200 OK`
> - [[http://127.0.0.1:8100/app/id/any\](http://127.0.0.1:8100/app/id/any%5C)]([http://127.0.0.1:8100/app/id/any\](http://127.0.0.1:8100/app/id/any%5C))\* for version 9.3.0 -\> `HTTP/1.1 200 OK`
> - [[http://127.0.0.1:8100/app/id/any\](http://127.0.0.1:8100/app/id/any%5C)]([http://127.0.0.1:8100/app/id/any\](http://127.0.0.1:8100/app/id/any%5C))\* for version 9.4.0

---

<div class="post-metadata">

**Author:** ![GeertVerbeurgt](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@GeertVerbeurgt](https://discuss.elastic.co/u/GeertVerbeurgt)\
**Post date:** [May 20, 2026, 2:29pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/24 "2026-05-20T14:29:33Z")

</div>

> [@GeertVerbeurgt](#):
>
> ```auto
> curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:9200/_cat/indices
> 
> curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:8100/api/spaces/space
> 
> curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:8100/app/id/any*
> 
> ```

@stephenb

You can see it in my previous post .

The base64-encoded string is the one generated for 'testuser'

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 20, 2026, 2:47pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/25 "2026-05-20T14:47:41Z")

</div>

great @GeertVerbeurgt , as I _ **was** _ able to completely reproduce with steps you gave, on my spare linux system

Several differences to how I tested before, you have disabled security completely here, I was using Mac before, ... but I see identical to you:

```auto
[2026-05-20T16:44:48.106+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
[2026-05-20T16:44:48.134+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
[2026-05-20T16:44:48.147+02:00][DEBUG][plugins.security.user-profile] Request to get current user profile is authenticated via Basic credentials.
[2026-05-20T16:44:48.147+02:00][DEBUG][plugins.security.user-profile] Activating user profile via password grant.
[2026-05-20T16:44:48.156+02:00][ERROR][plugins.security.user-profile] Failed to activate user profile: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}.
[2026-05-20T16:44:48.156+02:00][DEBUG][plugins.security.user-profile] Failed to activate profile via basic credentials: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}
[2026-05-20T16:44:48.157+02:00][ERROR][http] 500 Server Error

```

Minor adendum - if you make this call

> [@GeertVerbeurgt](#):
>
> ```auto
> curl -v -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' http://127.0.0.1:8100/app/id/any*
> 
> ```

as kibana is starting up, there's is a brief window where you will get the 200 back.

---

<div class="post-metadata">

**Author:** ![GeertVerbeurgt](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@GeertVerbeurgt](https://discuss.elastic.co/u/GeertVerbeurgt)\
**Post date:** [May 20, 2026, 2:53pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/26 "2026-05-20T14:53:27Z")

</div>

@RainTown @stephenb

I got this mail for my previous post :

```auto
Our automated spam filter, Akismet, has temporarily hidden your post in Elasticsearch Kibana 9.4.0 Basic authentication returns 401 Unauthorized for review. 

A staff member will review your post soon, and it should appear shortly. 

We apologize for the inconvenience .

```

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [May 20, 2026, 3:41pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/27 "2026-05-20T15:41:26Z")

</div>

Hi @GeertVerbeurgt

I reviewed your post, all good, reenabled your post, cause = lots of URLs triggers the 🤖

AND I reproduced your issue.

I do see accessing those URLs via `curl` worked on 9.3.0 with the `kibana_system` role  
I do see accessing those URLs via `curl` it did **NOT** work in 9.4.1with the `kibana_system` role

I did not understand you were using the `kibana_system` role for those `curl` s. I am still not sure if your intended use is to use `curl` for what you are trying to accomplish and why.

I will try to check internally if I can, no promise...  
But I suspect:  
A) That should not have ever worked for those URLs in the first place  
B) and / or may have been a security fix of some sort to tighten security  
C) All of the above

The `kibana_system` role is very specific, it not a role to access Kibana Assets / UI / Apps it is purely a role to allow the kibana server access elasticsearch as perform necessary functions. Personally, I am surprised that ever worked.

That role is not intended to be used externally in any way or for any other use. User beware.

> `kibana_system`
> 
> Grants access necessary for the Kibana system user to read from and write to the Kibana indices, manage index templates and tokens, and check the availability of the Elasticsearch cluster. It also permits activating, searching, and retrieving user profiles, as well as updating user profile data for the `kibana-*` namespace. This role grants read access to the `.monitoring-*` indices and read and write access to the `.reporting-*` indices. For more information, see [Configuring Security in Kibana](https://www.elastic.co/docs/deploy-manage/security/secure-your-cluster-deployment).

I suspect you will need to create a different user / role combination with the proper permissions if you want to use `curl` in the way you are showing to access UI elements etc.

Apologies if I am **still** missing the point

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 20, 2026, 3:55pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/28 "2026-05-20T15:55:11Z")

</div>

> [@stephenb](#):
>
> I do see accessing those URLs via `curl` worked on 9.3.0 with the `kibana_system` role  
> I do see accessing those URLs via `curl` it did **NOT** work in 9.4.1with the `kibana_system` role

Try with the other user created, with **superuser** role, created via

```auto
$ ./elasticsearch-users useradd testuser -p testpassword -r superuser

$ echo -n 'testuser:testpassword' | base64
dGVzdHVzZXI6dGVzdHBhc3N3b3Jk

```

You will likely find same diff from 9.3.0 (200 returned) to 9.4.0/9.4.1 (401, with kibana logging 500 Server Error)

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [May 20, 2026, 4:21pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/29 "2026-05-20T16:21:21Z")

</div>

> [@RainTown](#):
>
> You will likely find same diff from 9.3.0 (200 returned) to 9.4.0/9.4.1 (401, with kibana logging 500 Server Error)

"Likely" ? Sorry not following.

I just tested and both the `elastic` and `testuser` users both work for the use case as I would expect.

`./elasticsearch-users useradd testuser -p mypassword -r superuser`

`curl -k -H "Authorization: Basic <correctcreds>" "http://localhost:5601/app/id/any*"`

Just tested on 9.4.1 these both work because they a "user" roles not reserved / special roles

At this point I am totally confused

I just created a fully secured 9.4.1

I added

`./elasticsearch-users useradd testuser -p mypassword -r superuser`

```auto
 echo -n testuser:mypassword | base64                                                              
dGVzdHVzZXI6bXlwYXNzd29yZA==

```

`curl -k -H "Authorization: Basic dGVzdHVzZXI6bXlwYXNzd29yZA==" "http://localhost:5601/app/id/any*" > 9_4_1.txt`

Returns correct content

```auto
head 9_4_1.txt 
<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/><meta name="viewport" content="width=device-width"/><title>Elastic</title><style>
        
        @font-face {
          font-family: 'Elastic UI Numeric';
          font-style: normal;
          font-weight: 100 900;
          font-display: swap;
          src: url('/6b92ccb460a7/ui/fonts/elastic_ui_numeric/ElasticUINumeric-Variable.woff2') format('woff2');
          unicode-range: U+20, U+24-25, U+28-29, U+2B-2F, U+30-3A, U+A0, U+202F, U+2212;
        }
...

```

To me everything is working as expected....

- Special roles like `kibana_system` not intended for `curl` use do not work for the use case provided.
- User roles do work with `curl` for the use case provided
- It does look like something changed for the special / reserved roles between 9.3.0 and 9.4.0 I took a quick look in the repo I did not see anything specific but it is a big set of repos

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 20, 2026, 4:42pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/30 "2026-05-20T16:42:14Z")

</div>

> [@stephenb](#):
>
> "Likely" ? Sorry not following.

"Likely" meant only I'm not sure what you will see, so I don't want make assumptions 🙂

You referenced the users with the kibana\_system role, and thats acknowledged. But I had tested with the user created with **superuser** role exactly as @GeertVerbeurgt had written and done.

```auto
$ ./elasticsearch-users useradd testuser -p testpassword -r superuser
$ echo -n 'testuser:testpassword' | base64
dGVzdHVzZXI6dGVzdHBhc3N3b3Jk

```

And with that user, created exactly that way, using that Authorization header, I also see the error with 9.4.0 that I shared before, with these logs:

> [@RainTown](#):
>
> ```auto
> [2026-05-20T16:44:48.106+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
> [2026-05-20T16:44:48.134+02:00][DEBUG][plugins.security.authentication] Authentication is not required, as security features are disabled in Elasticsearch.
> [2026-05-20T16:44:48.147+02:00][DEBUG][plugins.security.user-profile] Request to get current user profile is authenticated via Basic credentials.
> [2026-05-20T16:44:48.147+02:00][DEBUG][plugins.security.user-profile] Activating user profile via password grant.
> [2026-05-20T16:44:48.156+02:00][ERROR][plugins.security.user-profile] Failed to activate user profile: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}.
> [2026-05-20T16:44:48.156+02:00][DEBUG][plugins.security.user-profile] Failed to activate profile via basic credentials: {"error":"no handler found for uri [/_security/profile/_activate] and method [POST]"}
> [2026-05-20T16:44:48.157+02:00][ERROR][http] 500 Server Error
> 
> ```

The way @GeertVerbeurgt had set things up here is a bit unconventional, with security pretty much entirely disabled, and using the user named accessuser , with only the kibana\_system role as the "connecting" user, that is defined in kibana.yml

> [@GeertVerbeurgt](#):
>
> ```auto
> server.port: 8100
> server.host: "127.0.0.1"
> server.ssl.enabled: false
> 
> elasticsearch.hosts: "http://127.0.0.1:9200"
> elasticsearch.username: accessuser <--- this user has only kibana_system role
> elasticsearch.password: accesspassword 
> 
> ```

though why bother if security is disabled at elasticsearch end!

Then he/I tested the curl commands **to kibana** with the creds of the other user, username=testuser, who has superuser role.

In all this, easy to lose sight of the initial issue, which is that he has apache in front of Kibana and had added the apache config he gave:

> [@GeertVerbeurgt](#):
>
> To login to Kibana, we use Apache configuration with an Authorization header via Basic Authentication ( needed for security reason ).
> 
> `RequestHeader set Authorization "expr=Basic {base64-encoded string}"`  
> `ProxyPass ``https://127.0.0.1:8100/`  
> `ProxyPassReverse ``https://127.0.0.1:8100/`

and the curl commands were just an easier way to try to debug that client \<-\> apache \<-\> kibana exchange and see where the "401" was coming from.

> [@stephenb](#):
>
> I just created a **fully secured** 9.4.1

I think this is a key difference. Because that is exactly what I had tested with already, and had been unable to reproduce, albeit with 9.4.0.

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [May 20, 2026, 4:51pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/31 "2026-05-20T16:51:15Z")

</div>

Thanks @RainTown I will let you take it from here... I am not really here debug proxy issue.

I am answering from what these roles are expected to do and not do.

I did find an Epic on tightening / auditing the `kibana_system` role / user. I suspect it was tightened as part of that.

> [@RainTown](#):
>
> And with that user, created exactly that way, using that Authorization header, I also see the error with 9.4.0 that I shared before, with these logs:

I just set up 9.4.1 and that works above... I just showed that... above... I can provide the Docker compose all commands.. I am very confident that works (no proxy, no other components just Elastic and Kibana)

I showed all the steps, the curl and the output so either there is a diference between 9.4.0 and 9.4.1 or one of us is doing something different / wrong.

the `curl` with role `superuser` should absolutely work.

I will let you two work it out from here ...

I will test 9.4.0 real quick to see if I see something different and report back

- There are role expected to be used with user interaction
- There are reserved / special roles that are not expected to be used by users.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 20, 2026, 5:03pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/32 "2026-05-20T17:03:43Z")

</div>

> [@stephenb](#):
>
> the `curl` with role `superuser` should absolutely work.

Absolutely. And I can make it not work, actually give an internal error, which is not ideal.

But that's only with Kibana and Elasticsearch with no security at all, sending calls with a header corresponding to auth for a superuser-role user.

Daft analogy, but the keys not working on a house with only wide open doors is a somewhat unusual issue.

I dont think 9.4.0 vs 9.4.1 will be any different.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 20, 2026, 5:11pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/33 "2026-05-20T17:11:31Z")

</div>

To respond back to you @GeertVerbeurgt , the setup which I agree reproduces an issue is ... a bit unusual.

If I merely enabled security in elasticsearch in 9.4.0, the error goes away

```auto
xpack.security.enabled: true

```

as seen here:

```auto
curl -v -s -H 'Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk' "http://127.0.0.1:38100/app/id/any*" > out.tx
t
* Trying 127.0.0.1:38100...
* Connected to 127.0.0.1 (127.0.0.1) port 38100
> GET /app/id/any* HTTP/1.1
> Host: 127.0.0.1:38100
> User-Agent: curl/8.5.0
> Accept: */*
> Authorization: Basic dGVzdHVzZXI6dGVzdHBhc3N3b3Jk
>
< HTTP/1.1 200 OK

```

Is that same for you?

Your 2 test setups had no security at all. That can't be your "real" setup, at time this thread started, though I appreciate you were trying to reduce to simplest reproducible case.

In your original report, you had this snippet:

`RequestHeader set Authorization "expr=Basic {base64-encoded string}"`  
`ProxyPass ``https://127.0.0.1:8100/`  
`ProxyPassReverse ``https://127.0.0.1:8100/`

What were the specific roles for the user corresponding to those base64 encoded creds?

And what are the roles for the user you are using in your kibana.yml

> [@GeertVerbeurgt](#):
>
> ```auto
> elasticsearch.hosts: "https://{elasticsearch hostname}:9200"
> elasticsearch.username: {username}
> elasticsearch.ssl.keystore.path: http_server.p12
> elasticsearch.ssl.truststore.path: truststore.p12
> 
> ```

It would be better to try duplicate that setup IMHO.

---

<div class="post-metadata">

**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\
**Post date:** [May 20, 2026, 5:21pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/34 "2026-05-20T17:21:16Z")

</div>

9.4.0 Same Behavior

@RainTown I think you are getting closer I think something in the "simplification" is getting lost

---

<div class="post-metadata">

**Author:** ![GeertVerbeurgt](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@GeertVerbeurgt](https://discuss.elastic.co/u/GeertVerbeurgt)\
**Post date:** [May 21, 2026, 11:04am UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/35 "2026-05-21T11:04:09Z")

</div>

@RainTown @stephenb

I have found the problem.

It was related to a special character ';' in the password of the login user, generated by a tool.

This was working until version 9.3.0. However, in the latest version, this causes problems during authentication.

Thank you so much for your help and support. I have already gained a few new insights into the elk stack.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 21, 2026, 2:41pm UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/36 "2026-05-21T14:41:54Z")

</div>

> [@GeertVerbeurgt](#):
>
> It was related to a special character ';' in the password of the login user

Great news!!

I believe ";" is an allowed character in elastic/kibana passwords, in that kibana 9.4.0 did not stop me using it, and the string:

```auto
$ echo -n 'testuser1:pass;pass' | base64
dGVzdHVzZXIxOnBhc3M7cGFzcw==
$

```

worked fine for me with all curls I tried using `-H 'Authorization: Basic dGVzdHVzZXIxOnBhc3M7cGFzcw=='` on my 9.4.0 system. So was your issue related to the proxy setup/handling of same, or ... ? Sorry, I'm not quite clear.

If `;` in existing (pre-9.4.0) user password would be causing issues that would only be seen in 9.4.0+, that would arguably be a quite subtle but annoying bug? I appreciate issue is solved for you, but if that solution is "dont use `;` characters in passwords" thats ... not great.

FYI a while ago I was involved in a thread where use of `!!` chars created bizarre issues in some scenarios, but that issue was [resolved](https://discuss.elastic.co/t/elasticsearch-reset-password-on-linux-cant-accept-special-characters/383050) around 9.1.5+.

---

<div class="post-metadata">

**Author:** ![GeertVerbeurgt](https://avatars.discourse-cdn.com/v4/letter/g/ba8739/32.png) [@GeertVerbeurgt](https://discuss.elastic.co/u/GeertVerbeurgt)\
**Post date:** [May 22, 2026, 8:58am UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/37 "2026-05-22T08:58:24Z")

</div>

@RainTown

I ran the test again to be sure ( on my real environment, changing the current password ) on version 9.3.0 and version 9.4.0 ( after update )

Apparently, it is **not ';'** , but **':'** that causes the problem. (Sorry for the confusion, my mistake). When **':'** is present in the password passed with the request header to Kibana, something is broken within Kibana version 9.4.0. In version 9.3.0, this is not a problem.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [May 22, 2026, 11:05am UTC](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318/38 "2026-05-22T11:05:15Z")

</div>

Thanks for double checking @GeertVerbeurgt

I reproduced this - a `:` in the password of a user with a superuser role seems to break the `-H 'Authorization: Basic xxxxx'` mechanism in 9.4.0. It's fine to login to kibana with that username and the password with the `:` in it. The same base64-encoded string works in 9.3.0 in both kibana and via the `-H...` scheme.

Personally, I'd say this is a bug. For same reasons as it would have been with a `;` character, or a `Z`, or any allowed-in-a-password character.

But I don't really know what the path `/app/id/any*` corresponds to in any real-world user flow.

I do note that /app/discover also generates a 401 in 9.4.0 and a 200 in 9.3.0. Actually so does /app/99redballoons. We are certainly in edge-case territory.

[Previous page](https://discuss.elastic.co/t/elasticsearch-kibana-9-4-0-basic-authentication-returns-401-unauthorized/386318.md?page=1)