CVE-2026-111280 is a High severity (CVSS 7.4) out-of-bounds write in snap7 through 1.4.3. A rogue or impersonated PLC can overflow client buffers with a crafted response. We could not confirm a fixed version, so isolate S7 traffic and check the project.
What's affected
The record says snap7 through 1.4.3 is affected. The reference is the davenardella/snap7 repository, with an issue number 31 as the report. The pages we read do not name a fixed release, so we do not state one. Check the repository for a release that addresses the issue.
The weakness is CWE-787, out-of-bounds write. Per the record, TSnap7MicroClient::opReadArea() trusts a DataLength field in the ReadVar response from the PLC. A malicious peer can set it so that up to 65535 bytes are copied into a buffer that the caller provided, which can corrupt memory and crash the host program.
The record names SCADA, HMI and gateway processes as the programs at risk. Severity differs by source. The record gives 7.4 (High), with high attack complexity. VulnCheck lists 8.3 on a CVSS 4.0 vector. Both are High.
How to check if you're exposed
Find software that links snap7. It is a library for talking to Siemens S7 controllers, so look in your build files, containers and vendor applications.
find / -name "*snap7*" 2>/dev/null
For source builds, check the dependency list and the version of the library. Versions through 1.4.3 are in range. Vendor applications may bundle their own copy, so ask suppliers whether they use snap7 and which version.
Then check the network. The attack needs the client to talk to a peer the attacker controls or can impersonate. A segmented control network where only known PLCs answer is a much smaller risk than a flat network. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Inventory every program that uses snap7, including bundled copies in vendor products.
- Check the repository for a fixed release and upgrade after confirming which version addresses the issue.
- Segment control networks, and limit which hosts can answer S7 requests, using firewall rules and switch port security.
- Add checks of response lengths in your own code if you call the library directly, until a fix is in place.
- Monitor SCADA and HMI processes for crashes and restarts, which may be the first sign.
Why it matters
Industrial protocols were designed for closed networks, and clients often trust the device on the other end. When the client believes a length field in a response, a rogue device can make it write past a buffer. Here the field allows up to 65535 bytes.
The effect is in the client, not the PLC. That reverses the usual picture, where the controller is the one at risk. A compromised or spoofed device on the network can attack the engineering and monitoring tools that talk to it. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
Who is at risk?
Programs that use the snap7 client library to read from S7 PLCs, such as SCADA, HMI and gateway software.
Is there a fixed release?
We could not confirm one. Check the davenardella/snap7 repository.
Sources
Last reviewed: 18 October 2026.
