V-SFT EUVD-2026-109625

Exploitation requires a user of V-SFT to open a maliciously crafted V7 file (the native file format parsed by the product); per the CVSS vector exploitation is local (AV:L) and requires active user interaction (UI:A), so there is no remote or network-facing attack surface and no authentication is needed by the attacker (PR:N) since the malicious file itself carries the payload. The principal limiting factors are: the attacker must deliver the crafted file to a victim and that victim must open it in V-SFT, confining realistic exploitation to social-engineering or supply-chain delivery of project files to ICS/HMI engineering workstations; impact is bounded to the vulnerable system (no scope change).

Signals point to a genuine but interaction-gated engineering-workstation risk rather than a remotely-wormable emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:A) describes a local, low-complexity flaw with no privileges needed but requiring the victim to actively open a crafted V7 file, yielding high confidentiality, integrity and availability impact on the vulnerable system (VC:H/VI:H/VA:H) with no scope change (SC/SI/SA:N) - consistent with a client-side file-parsing out-of-bounds write (CWE-787). The vuln.today decision label is 'this_week', indicating prompt but not drop-everything urgency. There is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active exploitation or a quantified exploitation probability; absence of these is not proof of safety but means widespread automated exploitation is not indicated. No public exploit or PoC reference is present in the input. The dependence on user interaction (an operator must be lured into opening a malicious project/screen file) is the dominant limiting factor and makes this a targeted social-engineering risk against ICS/HMI engineers rather than a mass-exploitation threat. Note the AV:L designation: this is not network-reachable, so 'remote' exploitation only occurs via file delivery, not direct network attack.

An attacker crafts a malicious V7 project/screen file and delivers it to an HMI engineer by phishing, a shared project repository, or a USB handoff. When the engineer opens the file in V-SFT, the out-of-bounds write is triggered, potentially leaking memory contents or executing attacker-controlled code in the context of the user running V-SFT. No public exploit code is identified in the available data, so this remains a plausible scenario rather than a demonstrated one.