Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
5DescriptionCVE.org
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.
- Obtain any valid token with only read scope.
- Connect to the normal production gRPC API (kuksa.val.v2).
- Open OpenProviderStream.
- Send ProvideSignalRequest for a target signal ID.
- Wait for the broker to forward GetProviderValueRequest.
- Reply with attacker-controlled GetProviderValueResponse.
- Other clients performing GetValue / GetValues for that signal receive forged data.
AnalysisAI
Eclipse KUKSA Databroker 0.5.0-0.6.0 allows privilege escalation from read-only JWT tokens to signal provider registration. Attackers with valid read-scope tokens can hijack the kuksa.val.v2 OpenProviderStream API to inject forged sensor/telemetry data into the vehicle data bus, poisoning downstream automotive systems and applications. CVSS 8.5 (High) reflects high integrity and availability impact across system and subsequent components. No active exploitation confirmed (not in CISA KEV), but the attack complexity is low and requires only low-privilege authentication.
Technical ContextAI
Eclipse KUKSA Databroker is a vehicle signal distribution middleware for automotive software-defined vehicles, implementing the COVESA Vehicle Signal Specification. The kuksa.val.v2 gRPC API provides OpenProviderStream for external signal sources to feed live data into the broker. CWE-306 (Missing Authentication for Critical Function) - the API fails to enforce JWT scope validation on the ProvideSignalRequest operation, accepting read-only tokens where provider/write scope should be mandatory. This allows token scope bypass: possession of any valid JWT (even with minimal read permissions) grants full signal provider capabilities. The affected CPE cpe:2.3:a:eclipse_foundation:eclipse_kuksa_-_databroker confirms versions 0.5.0 through 0.6.0.
RemediationAI
Upgrade to Eclipse KUKSA Databroker version 0.6.1 or later (vendor-released patched version per Eclipse Foundation advisory at https://gitlab.eclipse.org/security/cve-assignment/-/issues/98). The fix implements proper JWT scope validation on ProvideSignalRequest to require provider/write permissions. If immediate upgrade is not feasible, implement the following compensating controls: (1) Revoke and reissue all JWT tokens with read-only scope to use least-privilege principle - limit read tokens to monitoring-only clients that never require data injection; (2) Deploy network segmentation to restrict gRPC API access (default port TCP/55555) to trusted provider zones only, blocking read-only clients at firewall/service mesh layer (trade-off: breaks legitimate distributed read scenarios); (3) Enable gRPC access logging to detect anomalous OpenProviderStream usage by read-scoped tokens (provides detection but not prevention); (4) If your JWT issuer supports it, add custom claims to explicitly whitelist provider registration per token (requires application changes to both issuer and KUKSA). Advisory URLs: https://gitlab.eclipse.org/security/cve-assignment/-/issues/98 and https://nvd.nist.gov/vuln/detail/CVE-2026-6272.
More in Eclipse Kuksa Databroker
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-25409
GHSA-66v8-c34p-jmrm