Eclipse KUKSA Databroker CVE-2026-13699

Exploitation requires possession of a valid JWT token accepted by the target Databroker instance - the description explicitly states that unauthenticated requests and requests carrying invalid tokens are rejected before reaching the vulnerable code path. The attacker must target the specific kuksa.val.v2.VAL/PublishValue gRPC method with a crafted PublishValueRequest that supplies a recognized signal_id while omitting the optional data_point field. The impact is strictly bounded: only the individual panicking RPC call is cancelled; the Databroker process survives and continues serving subsequent requests normally. This limits exploitation to a per-call disruption rather than a full service outage. No special deployment configuration, platform variant, or non-default feature is required beyond the authentication prerequisite.

The provided CVSS 3.1 score of 4.3 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L accurately reflects the constrained impact of this vulnerability. PR:L is consistent with the description's explicit statement that only clients holding a valid JWT token can reach the vulnerable code path, meaning the attacker population is already limited to authenticated parties. The availability impact is rated Low (A:L) because the panic terminates only the individual gRPC call and not the Databroker process, which remains operational - this is a disruption to the caller's session, not a service-level outage. No EPSS score was provided, preventing probabilistic exploitation assessment. The absence of KEV listing and no reported POC further reduce urgency. The primary real-world concern is a malicious or compromised in-vehicle component with a token deliberately exhausting Databroker processing capacity through repeated panic-triggering requests, degrading signal throughput. The tags list 'Information Disclosure,' which is inconsistent with the CVSS C:N impact and the description - this appears to be a mislabeling; available data does not support any confidentiality impact.

An attacker or compromised in-vehicle software component with a valid JWT token connects to the Databroker's gRPC interface and sends a PublishValueRequest that includes a legitimate signal_id but deliberately omits the data_point field. The server calls unwrap() on the absent field, triggering a Rust panic in the Tokio async worker thread, which cancels that specific RPC invocation and returns an error to the client. By sending these requests in rapid succession, the attacker could degrade the throughput of signal updates processed by the Databroker, though the process itself continues running and remains reachable.