For people who are following this thread, I want to make a clarification about this issue (and apologized for not making it clear at the beginning)
This issue will ONLY happen to users who are using the JWT authentication provider. If you are using other authentication providers, you are NOT impacted. If you are using a JWT authentication provider, you don't need to be panic as well. If you have already configured `roleClaim`, `audienceClaim`, and `audience` for your JWT auth provider, you are well protected in general. Because the JWT authentication provider will verify the audience. Unless the attacker knows all the above fields, they will not able to mock a token to bypass the JWT auth provider. Also, the issue can ONLY allow a token to be authenticated with a NONE signing algorithm. An authenticated user doesn't directly gain any access. It will still go through the authorization process. Because all the Pulsar roles are NOT predefined. That Pulsar role names are generated, configured, and managed by the users. Unless the attacker knows your roles, they won't be able to mock a token to access your cluster. So there is a couple of recommendations for everyone here: 1) Make sure you enable the authorization provider to authorize any connections coming to Pulsar. 2) Your superuser roles are typically configured in the broker conf. Please don't use those popular strings like `admin`, `superuser` as your superuser roles. So the attacker won't be able to guess or brute-force your role names. 3) You SHOULD configure the `roleClaim`, `audienceClaim`, and `audience`. Let me know if you have any questions. Feel free to ping me if you need any helps. - Sijie On Tue, May 25, 2021 at 6:27 AM PengHui Li <peng...@apache.org> wrote: > CVE-2021-22160 Apache Pulsar Information Disclosure > > Severity: High > > Versions Affected: > Apache Pulsar < 2.7.1 > > Description: > If Apache Pulsar is configured to authenticate clients using tokens > based on JSON Web Tokens (JWT), the signature of the token is not > validated if the algorithm of the presented token is set to "none". > This allows an attacker to connect to Pulsar instances as any user > (incl. admins). > > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > Upgrade to Apache Pulsar 2.7.1 or later > > Credit: > This issue was identified by Peter Stöckli >