AppScan Azure Boards EUVD-2026-108086

Two conditions must both hold: (1) the AppScan Azure Boards Plugin must be configured to communicate with the AppScan server over HTTP rather than HTTPS - a non-recommended configuration that the updated plugin now warns against; and (2) the attacker must occupy a network position able to observe or intercept that plugin-to-server traffic. Deployments using HTTPS are not exposed. Limiting factors: exploitation is passive-interception dependent (requires man-in-the-path access), yields only data in transit (credentials/tokens), and causes no integrity or availability impact; AC:H reflects the required interception vantage combined with the non-default HTTP configuration.

This is a low-severity, low-priority issue, and the signals are consistent in saying so. The vendor CVSS base score is 2.2 (CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N), the only impact is limited confidentiality (C:L; I:N/A:N), and the vuln.today Decision label is 'monitor' - not act_now or emergency. There is no CISA KEV listing, no public exploit or PoC reference in the supplied data, and no EPSS score was provided, so exploitation probability cannot be quantified from this input. The attack is a classic cleartext-transmission exposure (CWE-319) that only yields intercepted credentials/tokens if the plugin is deliberately configured to talk to the AppScan server over HTTP and an attacker already holds a traffic-interception position. One metric is worth scrutinizing: the vendor vector uses PR:H, but a passive/active network interceptor of cleartext traffic does not normally need any privilege on the target - the HTTP setting is an operator configuration choice, not an attacker privilege. This likely reflects how HCL modeled the precondition rather than true attacker-held privileges; treat PR:H as vendor-assigned and verify intent with HCL. Net: a real but minor hardening issue, not an urgent patch priority.

An AppScan Azure Boards Plugin deployment is configured to reach the AppScan server over plain HTTP. An attacker positioned on the network path (e.g., a shared LAN segment, compromised intermediary, or ARP/DNS spoofing vantage) passively captures the plugin-to-server traffic and reads the credentials or authentication tokens sent in cleartext, then reuses them against the AppScan server. No public exploit code or PoC reference is present in the supplied data.