Authorization bypass in kuksa.val.v2 allows read-scope provider hijack
Was asked to open ticket here in https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/384
## Steps to reproduce
A client holding only a read JWT scope can still register itself as a signal provider through the production kuksa.val.v2 OpenProviderStream API by sending ProvideSignalRequest.
1. Obtain any valid token with only read scope.
2. Connect to the normal production gRPC API (kuksa.val.v2).
3. Open OpenProviderStream.
4. Send ProvideSignalRequest for a target signal ID.
5. Wait for the broker to forward GetProviderValueRequest.
6. Reply with attacker-controlled GetProviderValueResponse.
7. Other clients performing GetValue / GetValues for that signal receive forged data.
## What are the affected versions?
Probably everything supporting kuksa.val.v2 API introduced in 0.5.0
0.5.0 until 0.6.0
## Do you know any mitigations of the issue?
Upgrade to 0.6.1
<!--
Please, do not remove the line below. It will create a confidential issue that will be visible
only to you and the members of this project. Confidential issues are used to keep security
vulnerabilities private until they are sorted out.
Eclipse Projects follow Responsible Disclosure best practices: the initial report is made privately,
but with the full details being published once a patch has been made available (sometimes with
a delay to allow more time for the patches to be installed).
-->
issue