Eclipse Kuksa Databroker
Approved changes feed: RSS · Atom
cpe:2.3:a:eclipse_foundation:eclipse_kuksa_-_databroker:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | Eclipse Foundation (2c315c48-0111-5572-bbde-cc70cfafb2e9) |
|---|---|
| Product | Eclipse Kuksa Databroker (e00b929f-f9e1-51f4-8659-95fd76f78d13) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-13699 |
vulnerable | 2026-07-29 00:23:33.231636 |
Databroker 0.6.1 PublishValue missing data_point panic
MEDIUM (4.3)
In Eclipse KUKSA Databroker version 0.6.1, the kuksa.val.v2.VAL/PublishValue gRPC handler fails to validate the existence of the optional data_point field in PublishValueRequest. When a request contains a valid signal_id but omits data_point, the server directly calls unwrap() on request.data_point, triggering a panic in the Tokio worker thread. This issue can be triggered by any client holding a valid JWT token. Unauthenticated or invalid-token requests are rejected and do not reach the vulnerable path. The panic causes the individual gRPC call to be cancelled but does not terminate the Databroker process, which remains available for subsequent requests.
Published: 2026-07-14T07:38:23.271Z
Updated: 2026-07-14T12:32:37.446Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-6272 |
vulnerable | 2026-06-08 08:07:04.614989 |
Details available
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.
Published: 2026-04-24T08:28:17.690Z
Updated: 2026-04-24T11:29:18.312Z Reference links |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.