HCL DFXAnalytics EUVD-2026-44916

Exploitation requires the attacker to hold a man-in-the-middle or traffic-interception position on the network path between the victim and DFXAnalytics (version 3.0 or below), AND for the victim's browser to actually issue a request to the application over unencrypted HTTP rather than HTTPS - for example via a forced HTTP navigation, an HTTP-scheme link, mixed content, or an SSL-stripping attack. The limiting factors are significant: if the deployment serves only HTTPS with HSTS (ideally preloaded), browsers will not send the cookie over HTTP and the flaw is effectively inert; exploitation also yields only the cookie/token (Technical Impact: partial), not direct code execution, and the attacker must be positioned on the network rather than acting from anywhere on the internet despite the AV:N rating.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2) rates this High, but the combined signals point to materially lower real-world risk. The vulnerability is only exploitable when an attacker can already intercept or coerce cleartext traffic, which in practice raises attack complexity above the AC:L the vendor assigned. EPSS is 0.17% (7th percentile) and CISA SSVC reports Exploitation: none, Automatable: no, Technical Impact: partial - all consistent with a low-urgency, non-wormable, opportunistic issue. There is no KEV listing and no public exploit. One tension worth verifying with the vendor: the scope-changed, network, low-complexity rating implies easy remote impact, yet the described attack fundamentally depends on the attacker occupying a man-in-the-middle position and on the client actually making an HTTP request - non-trivial preconditions. Overall this is a legitimate hardening defect to fix on a normal patch cycle, not an emergency.

An attacker on the same LAN, public Wi-Fi, or an on-path network segment as a DFXAnalytics user waits for or coerces (via an HTTP link or mixed-content asset) the victim's browser to send a request to the application over HTTP. Because the session cookie lacks the Secure flag, the browser attaches it to that cleartext request, and the attacker sniffs the token and replays it to hijack the authenticated session. No public exploit code is required - capturing an unencrypted cookie is a standard, well-understood technique.