EUVD-2026-43634
GHSA-ccmw-x5fc-v2mm
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
JWT authentication requirement confirmed by description and PR:L; A:L reflects per-call panic with process survival, not service-level outage.
Primary rating from Vendor (eclipse).
CVSS VectorNVD
Lifecycle Timeline
2DescriptionNVD
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.
AnalysisAI
Eclipse KUKSA Databroker 0.6.1 panics in a Tokio worker thread when an authenticated client sends a PublishValueRequest with a valid signal_id but omits the optional data_point field, causing the server to call Rust's unwrap() on a None value. Any client holding a valid JWT token can trigger this condition, cancelling the individual gRPC call while leaving the Databroker process intact and available. No public exploit has been identified and this vulnerability is not listed in CISA KEV; EPSS data was not supplied in available intelligence.
Technical ContextAI
Eclipse KUKSA Databroker is an automotive and IoT vehicle signal broker implementing the kuksa.val.v2 gRPC API, as identified in CPE cpe:2.3:a:eclipse_foundation:eclipse_kuksa_-_databroker:*:*:*:*:*:*:*:*. The vulnerable handler is kuksa.val.v2.VAL/PublishValue, which processes signal updates from in-vehicle or connected clients. The root cause is CWE-20 (Improper Input Validation): the handler does not check for the presence of the optional protobuf data_point field before consuming it. In Rust, calling unwrap() on an Option<T> that contains None triggers a panic, which in an async Tokio runtime propagates as a task failure, aborting the specific worker handling that RPC call. The protobuf definition marks data_point as optional, making its absence a valid but unhandled input case that the server must explicitly guard against.
RemediationAI
A vendor-released patched version is not independently confirmed from the available data; organizations should monitor the Eclipse security advisory at https://gitlab.eclipse.org/security/cve-assignment/-/work_items/148 for an official fix release and apply it promptly. As an interim compensating control, operators should strictly limit JWT token issuance to explicitly trusted and audited clients, reducing the set of actors capable of reaching the vulnerable endpoint - token revocation for any compromised or untrusted client is a direct mitigation. Deploying a gRPC reverse proxy or middleware that validates the presence of required fields in PublishValueRequest before forwarding to Databroker would block malformed requests entirely; the trade-off is added operational complexity and latency. Rate-limiting authenticated clients on the PublishValue endpoint can reduce the throughput impact of repeated panic-triggering but does not eliminate the vulnerability. Since the panic is non-fatal and process availability is preserved, the residual risk of unpatched deployments with controlled token populations is low.
More in Eclipse Kuksa Databroker
View allSame weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today