Telerik Fiddler Everywhere CVE-2026-86157

Exploitation requires ALL of: (1) local access to the machine as a low-privileged user (PR:L, AV:L); (2) the ability to modify Fiddler Everywhere's application launch parameters, which exposes its privileged IPC functionality; and (3) user interaction - the victim must actually start the application (UI:R) after the parameters are tampered with. These conditions confine the attack to a shared or already-compromised developer endpoint; it is not remotely reachable and there is no availability impact (A:N). Patching to Fiddler Everywhere 8.2.0 or later removes the exposed IPC surface.

This is a moderate, developer-workstation-scoped risk rather than an urgent priority. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N, score 5.6) confirms the attack is LOCAL, requires an already-authenticated low-privileged foothold, and additionally requires user interaction (the victim must launch the application). This combination substantially raises the exploitation bar versus a remote-unauthenticated flaw. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis.' The single confirmed intelligence signal is the vendor (Progress) self-reported advisory plus a patch (8.2.0). SSVC-style reading: exploitation=none observed, not automatable (needs local access + social engineering to start the app), technical impact is partial (confidentiality-high for OAuth tokens but no availability impact). The CWE-749 (exposure of dangerous/privileged IPC) is well matched to the description; note the input Tag 'Authentication Bypass' conflicts with the actual weakness class and should be treated as mislabeled. Net: a legitimate hardening fix worth patching on developer machines, but not a widespread emergency.

An attacker with an existing low-privileged local account (or malware already present on a shared developer machine) alters Fiddler Everywhere's launch parameters to point its privileged IPC surface at attacker-controlled content, then waits for or convinces the developer to start the application. On launch, the injected content replaces the UI/settings and can exfiltrate stored OAuth authentication tokens, run locally accessible programs, or tamper with Fiddler-generated configuration files. No public exploit code is identified, so this remains a demonstrated-by-vendor risk rather than an actively exploited one.