Authorization bypass in kuksa.val.v2 allows read-scope provider hijack

Was asked to open ticket here in vulnerability-reports#384 (closed)

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