Snap7 EUVD-2026-108711

Exploitation requires a Snap7 instance acting as a passive BSend/BRecv partner, listening on TCP/102, with an application that calls BRecv or registers an OnBRecv callback using a buffer sized for its expected payload - the API provides no way to declare that buffer's capacity, so correctly-written callers are still exposed. The malicious active partner must connect from (or spoof) the configured remote peer address; S7 provides no authentication, so this check offers no cryptographic protection but does constrain the attacker to the expected peer identity/network path (this is the AT:P requirement). The trigger is explicitly described: declare a BSend TotalPackSize up to 65535 while sending only a short fragment, so the stored declared length - not the bytes actually reassembled - becomes the memcpy size. Limiting factors: only the passive-partner role is affected, the attacker must reach TCP/102 and match the configured peer address, and only versions through 1.4.3 are vulnerable; there is no user interaction and no authentication barrier once peer reachability is achieved.

The CVSS 4.0 base score of 8.3 (AV:N/AC:L/AT:P/PR:N/UI:N) reflects a network-reachable, unauthenticated memory-corruption flaw with high integrity and availability impact (VI:H/VA:H) but no confidentiality impact (VC:N) - consistent with an out-of-bounds write that crashes or corrupts rather than leaks data. The key tempering signal is AT:P (attack requirement present): the write path is reached by an active partner 'connecting from the configured peer address,' so an attacker must reach TCP/102 and match/impersonate the configured peer rather than hit any open endpoint. S7 has no authentication, so that peer check is spoofable on a network the attacker can reach, but it still limits mass, internet-wide exploitation. There is no EPSS score in the input and the CVE is not in CISA KEV, so exploitation status is: no public exploit identified at time of analysis - though the reporter (Telmo Xavier, CGI España, via VulnCheck) states a working AddressSanitizer PoC exists privately and is being withheld (advisory SNAP7-TX-2026-01). The vuln.today decision label is 'this_week,' not act_now/emergency, which aligns with a confirmed-but-not-yet-publicly-weaponized OT library flaw. Net: a genuine priority for operators running Snap7 passive partners in SCADA/HMI/gateway roles given the impact to industrial processes, but the peer-address requirement and absence of KEV/EPSS signals point to targeted rather than opportunistic exploitation. Note that both the input CVSS 4.0 vector (AC:L with AT:P) and a 3.1 reading (where the peer requirement maps to AC:H) describe the same constraint differently - verify which model your prioritization pipeline expects.

An attacker able to reach a listening Snap7 passive partner on TCP/102, presenting the configured remote peer address (S7 has no authentication, so this is spoofable), begins a BSend sequence that declares a TotalPackSize of up to 65535 bytes but transmits only a short fragment. Because FRecvLast.Size is taken from the declared length rather than the bytes actually reassembled, BRecv (or CheckAsBRecvCompletion on the async path) memcpy's the declared length into the application's receive buffer with only a NULL check, overflowing it and crashing or corrupting the host SCADA/HMI/gateway process. No public exploit exists; the reporter holds a private ASan PoC.