Answer in brief
CVE-2026-13699 records a Medium severity (CVSS 4.3) vulnerability in Databroker 0.6.1 PublishValue missing data_point panic. The current sources do not mark it as known exploited. The current feed maps Eclipse Foundation/Eclipse KUKSA - Databroker (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 4.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Eclipse Foundation/Eclipse KUKSA - Databroker (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Eclipse Foundation/Eclipse KUKSA - Databrokergeneric | 0.6.1 | Not reported |
Published upstream
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 14, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-13699 records a Medium severity (CVSS 4.3) vulnerability in Databroker 0.6.1 PublishValue missing data_point panic. The current sources do not mark it as known exploited. The current feed maps Eclipse Foundation/Eclipse KUKSA - Databroker (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 4.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Eclipse Foundation/Eclipse KUKSA - Databroker (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Eclipse Foundation/Eclipse KUKSA - Databrokergeneric | 0.6.1 | Not reported |
Published upstream
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 14, 2026
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.
Quoted source text, attributed separately from HOL analysis.