Eclipse Ditto Explorer CVE-2026-107503

Requires the Ditto Explorer UI (versions 3.6.0 through 3.9.7) with the autoSso single-sign-on feature enabled, and the victim must open an attacker-crafted link that sets an attacker-controlled OIDC authority or api_uri; the victim must then authenticate at the genuine identity provider so that an authorization code and PKCE code_verifier are generated and redirected to the attacker's token endpoint. Limiting factors: exploitation needs active user interaction (clicking the crafted link, matching UI:A) and the OIDC/autoSso configuration path, so default deployments without OIDC-based login are not exposed; however, because the injected configuration is persisted, the victim's later visits re-trigger token theft without the link.

This is a credible but conditional account-takeover flaw rather than a mass-exploitation emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:A) correctly captures that it is network-reachable and needs no attacker privileges, but materially gated by two factors: a required attack precondition (AT:P - the autoSso feature must be enabled and the victim must authenticate at the genuine IdP) and active user interaction (UI:A - the victim must open the attacker's crafted link). The high subsequent-system impact (SC:H/SI:H) is justified because the stolen OAuth access/refresh tokens compromise the victim's identity at the real IdP, extending beyond the Ditto UI itself. No EPSS score, KEV listing, or POC was provided in the input, so exploitation signals are absent: no public exploit identified at time of analysis and no evidence of active exploitation. Net priority: treat as a genuine high-severity issue for any environment actually running the affected Ditto Explorer UI with OIDC/autoSso, but the niche deployment footprint and user-interaction requirement make widespread opportunistic exploitation unlikely. Note the tag 'Code Injection' conflicts with CWE-15 (External Control of System or Configuration Setting) - this is a configuration/redirect-injection flaw, not code execution.

An attacker sends a victim Ditto Explorer operator a crafted link that sets an attacker-controlled OIDC authority (or api_uri) with autoSso enabled. The UI silently begins a login at the legitimate identity provider, but exchanges the returned authorization code plus its PKCE code_verifier at the attacker's token endpoint, handing the attacker the victim's access and refresh tokens. No public exploit code was identified in the provided data; because the malicious configuration persists, later normal visits to the UI keep leaking tokens.