Secure Connect Gateway EUVD-2026-85312

Requires the attacker to occupy an adjacent-network, man-in-the-middle position relative to Dell SCG Policy Manager (versions prior to 5.34.00.16) TLS traffic - e.g. ARP/DNS spoofing on a shared LAN segment - and to present a forged certificate that the improperly-validating client accepts. Limiting factors: exploitation is NOT possible from arbitrary remote/internet locations (AV:A, not AV:N), demands high attack complexity to establish and sustain the intercept (AC:H), and yields no availability impact. Network segmentation, mutual TLS/certificate pinning, and restricting the gateway to trusted segments materially reduce feasibility.

This is a moderate, defense-in-depth-grade issue rather than a top-priority emergency. The vendor CVSS 3.1 vector (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, base 6.8) tells a consistent story: an unauthenticated attacker, but one who must be on an adjacent network (AV:A) AND already hold a man-in-the-middle position with high attack complexity (AC:H) to abuse the improper certificate validation (CWE-295). The high confidentiality and integrity impacts only materialize once that MitM position is achieved - this is a classic TLS-trust-bypass flaw, not a directly remotely-triggerable RCE. No EPSS score, KEV entry, or public PoC is present in the provided intelligence, and it is Dell self-reported via DSA-2026-385 with no evidence of exploitation, so exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (no CVSS-vs-description conflict), which lowers uncertainty. Note one data discrepancy: the description and CPE indicate fixed version 5.34.00.16, but the ENISA EUVD affected-range string reads '<5.36.00.16 or later,' which appears to be a transcription artifact - treat 5.34.00.16 as the authoritative patched version pending vendor confirmation. Net: real but conditional risk; prioritize behind any internet-facing/unauthenticated-RCE items but patch as part of normal Dell SCG maintenance, especially on flat/shared network segments where MitM is feasible.

An attacker positioned on the same or an adjacent network segment as the SCG Policy Manager (e.g. via ARP spoofing, rogue DHCP/DNS, or a compromised switch) intercepts the gateway's TLS connections and presents a fraudulent certificate that the client fails to validate. Because certificate validation is improper, the attacker decrypts and can tamper with the exchanged support/telemetry traffic, disclosing sensitive data and bypassing the intended TLS protection mechanism. No public proof-of-concept is available, and the high attack complexity reflects the need to first establish and maintain the MitM position.