Traccar CVE-2026-108738

Exploitation requires the Traccar instance to have OpenID Connect / OAuth SSO login configured and enabled - this is not Traccar's default authentication mode, which sharply narrows the exposed population. The attacker must possess their own valid authorization code from the same OIDC provider and induce the victim's browser to load /api/session/openid/callback (passive user interaction, UI:P). The flaw is that the /api/session/openid/callback handler never validates the OAuth state parameter, so any attacker-supplied code is accepted. Limiting factors: SSO must be configured (non-default), the victim must be enticed to follow an attacker link, and impact is confined to the victim's data being written into the attacker's account rather than takeover of the victim's account.

This is a genuinely low-priority issue and the signals agree on that. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N) scores only 2.3 - network-reachable and unauthenticated, but requiring passive user interaction (UI:P) and a present attack requirement (AT:P, i.e. the attacker must supply a valid OAuth authorization code from their own account and win a timing/flow race). Impact is limited to low confidentiality and low integrity with no availability or scope impact, consistent with a login-CSRF class flaw (CWE-352) rather than server compromise. No EPSS score, KEV listing, or explicit POC flag was provided in the input; however, a detailed public technical write-up exists (hackmd.io) alongside pinned source-line references, so the mechanism is fully documented even if packaged exploit code is not confirmed. No conflicting signals of note, but one caveat: the CVSS marks PR:N (unauthenticated), yet real exploitation is gated on the target deployment having OpenID Connect SSO configured - a non-default condition the base vector does not capture. Net: a real but minor, conditional CSRF affecting a niche class of SSO-enabled Traccar deployments, not an urgent patch-tonight item.

An attacker running OIDC SSO against the same provider as a target Traccar instance obtains their own valid authorization code, then lures a logged-in or about-to-log-in victim into loading /api/session/openid/callback with that code. Because the OAuth state parameter is never validated, the victim's browser is silently logged into the attacker's account, and any devices or data the victim subsequently registers land in the attacker's account. A public technical write-up documents the flow, but no packaged exploit code is confirmed in the provided data.