snap7 crash via S7comm Read Variable count=0xFFFF — OpenPLC S7comm server affected

[alosafuzz]

OpenPLC Runtime bundles the snap7 library to provide an S7comm server interface
on port 102. A vulnerability in snap7's Read Variable handler allows any unauthenticated
network client to crash the snap7 server process with a single request containing
element count=0xFFFF (65535).

This has been reported upstream to the snap7 project (github.com/SCADACS/snap7).
OpenPLC will be affected until snap7 releases a patched version.

Note: this was confirmed on a test deployment running thiagoralves/OpenPLC_v3
(the archived predecessor of this repo) — since that repo is archived and can no
longer take a patch upstream, existing v3-based field deployments (a large
installed base — 1568 stars / 96 forks on the old repo) may need a migration
notice or advisory covering both codebases, since they share the vulnerable
snap7 integration.

Workaround (until patched): Firewall port 102 to trusted S7comm clients only.
In OpenPLC's settings, disabling S7comm (snap7|false in openplc.db) prevents exposure
if S7comm access is not required for the deployment.

PoC available on request (will share after coordination with snap7 maintainers).

Researcher contact: Shad Malloy, shadmalloy3@gmail.com

[alosafuzz]

Two more findings from the same testing pass (not related to the snap7 crash above)

While testing the S7comm crash reported in this issue, I came across two more things
worth documenting here — neither is a snap7 bug, so I'm folding them into this thread
rather than opening new issues.

---

1. Modbus TCP: exception responses have a corrupted MBAP header

OpenPLC's Modbus TCP server sends exception responses with an incorrect MBAP header.
The Protocol Identifier field is set to 0x0001 instead of the required 0x0000.
In some cases the Transaction Identifier field is corrupted as well. This affects
every request path that triggers a Modbus exception response (illegal function,
illegal data address, etc.) — confirmed across 54 distinct fuzz cases.

Example — request (unit_id=0x00, function code 0x03 Read Holding Registers):

00 01 | 00 00 | 00 06 | 00 | 03 | 00 00 | 00 01
TID=1   proto=0 len=6  uid=0 FC03 addr=0  count=1

OpenPLC's response (function code 0x03 not valid for unit 0x00, so an exception is expected):

00 01 | 00 01 | 00 03 | 01 | 83 | 01
TID=1   proto=1 len=3  uid=1 FC=0x83 (exception) exc=0x01
        ^^^^^ BUG: proto_id should be 0x0000

When the request's unit_id differs further from the configured device UID (e.g. 0x03
instead of 0x01), the corruption is worse — both TID and proto_id come back garbled:

Request:  unit=0x03
Response: 00 26 | 01 03 | 00 03 | 01 | 83 | 01
          TID=38  proto=0x0103  <- completely corrupted MBAP

Impact: Low severity — spec-compliance issue, not a crash or DoS. A strict Modbus
TCP client/SCADA master that validates the MBAP Protocol Identifier field per spec
(IEC 61158-6-3 requires proto_id=0x0000) may reject these responses as malformed,
causing communication failures with well-behaved clients rather than any security
impact.

Trigger: Any request that causes OpenPLC to generate a Modbus exception response —
most simply, a user-defined/reserved function code (0x41–0x45), or a function code
sent to a unit_id the device doesn't recognize.

Suggested fix: Set the Protocol Identifier field to 0x0000 (fixed value, not
derived from the request) when constructing the exception response MBAP header, and
ensure the Transaction Identifier is copied from the originating request unmodified.

---

2. S7comm: unauthenticated PLC Stop command is accepted and executed

Also while testing the crash above, I confirmed OpenPLC accepts and executes an
unauthenticated S7comm PLC Stop command (S7 function code 0x29). Any client that can
complete the standard COTP + Setup Communication handshake on port 102 can halt the
running PLC program — no credentials required.

This isn't a snap7 implementation bug — S7comm has no authentication mechanism at the
protocol layer, by design (a known, longstanding limitation of the protocol itself,
not specific to this codebase). I'm not requesting a CVE for it, but it's meaningful
attack surface for anyone running OpenPLC's S7comm server on a reachable network, so
it seemed worth documenting alongside the crash finding rather than leaving it
unreported.

Impact: Any network client with access to port 102 can stop the PLC runtime with
a single unauthenticated request, causing loss of control/availability — independent
of the Read-Variable crash bug reported above.

Suggested mitigation (necessarily application-layer, since S7comm itself has no auth):

• Firewall port 102 to trusted engineering/HMI hosts only (same recommendation as for
  the crash bug above)
• Consider an OpenPLC-level allowlist or confirmation step for state-changing S7comm
  commands (Stop/Start), if feasible within the runtime's architecture
• Document this as a known limitation in OpenPLC's S7comm deployment guidance, since
  it's easy for an integrator to assume S7comm has some baseline access control

---

Happy to provide more detail or a reproduction script for either of these on request.

Researcher contact: Shad Malloy, shadmalloy3@gmail.com

[alosafuzz]

S7Comm connection-exhaustion DoS + two Modbus server bugs + an OPC-UA anonymous role-elevation gap on servers with no configured users — Runtime v4

Hi again — following up on the earlier report in this thread. While re-testing the
snap7 crash finding against Runtime v4 (via a fresh v4-native project with Modbus,
S7Comm, and OPC-UA servers configured through the Editor), I found a more actionable
issue in the S7Comm plugin, two smaller bugs in the Modbus server plugin, and an
access-control gap in how the OPC-UA server assigns roles to anonymous sessions when a
project has no configured users. Filing all four together since they came out of the
same testing pass.

(Edited 2026-07-18: section 4 corrected after a closer source review — the original
wording overstated it. See the note at the top of that section.)

1. S7Comm connection-exhaustion DoS (root cause: no per-connection timeout)

Summary

The S7Comm plugin has no read/processing timeout on individual client connections. Any
input that leaves the S7 parser waiting for more data — a truncated frame, or a
structurally complete frame with certain invalid field values — holds that connection's
slot in max_clients indefinitely (until the plugin's own longer keepalive/reap cycle,
roughly 5-10 seconds, eventually clears it). An attacker can hold enough connections
open simultaneously to exhaust max_clients (default 32) and deny service to every
legitimate S7Comm client.

Trigger vectors (4 found, likely not exhaustive)

Each of these, sent on an otherwise-normal connection, causes that connection to hang
indefinitely rather than getting a response or a proper error:

1. A truncated Setup Communication frame (tested at 1, 4, 7, 10, 15, 20 bytes)
2. A Read Variable request with function_code set to anything other than the correct
   0x04 (tested 0x00, 0x01, 0xFF — all three hang identically)
3. An S7 header with ROSCTR=0x07 (UserData) sent as a Job-style request
4. A TPKT header with total_len=0

Reproduction

Confirmed both mechanisms cause the same lockout independently:

• ~35-40 connections held open via truncated Setup Communication frames
• ~35 connections held open via trigger Fix core compilation #2 (function_code=0x00)

Both scenarios: a fresh, well-formed client attempting the standard COTP CR → CC →
Setup Communication handshake gets no response to its COTP CR (empty read) while the
malicious connections are held. The condition clears on its own after roughly 5-10
seconds even without closing the malicious connections, consistent with an internal
keepalive/reap timer rather than a hard resource leak — but it's trivially re-triggered,
so an attacker can maintain continuous denial by re-flooding every few seconds.

I'm not including a ready-to-run flood script in this public thread, to avoid handing
anyone a working DoS against production OT deployments — happy to share the exact PoC
privately on request.

Impact

Any client with network access to the S7Comm port can deny service to every legitimate
S7Comm client (HMIs, SCADA, engineering stations) using ~35-40 connections and a handful
of bytes each — no authentication required, since S7Comm has none. Sustainable
indefinitely with periodic re-flooding.

Suggested fix

Add a read/processing timeout per connection (e.g., abandon and close a connection that
hasn't completed a well-formed request within N seconds of the last byte received),
independent of the existing keepalive/reap cycle. That alone would close all 4 known
trigger vectors, since they all rely on the same missing-timeout behavior rather than
being independent parsing bugs.

CVSS 3.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — 7.5 HIGH (same vector as the original
count=0xFFFF crash report — comparable unauthenticated, network-reachable DoS, arguably
easier to execute since it needs only connection volume, not a precise byte-level
trigger).

---

2. Modbus server: pipelined/multi-ADU requests hang the server (100% reproduction)

Summary

If a client sends two well-formed Modbus ADUs concatenated in a single TCP segment (e.g.
a coil write immediately followed by a read, same sendall()/packet), the server never
responds to either. Reproduced in 21/21 test cases covering different ADU pairings.

This isn't just an attacker scenario — TCP doesn't guarantee segment boundaries match a
client's individual send() calls, so any Modbus master that pipelines requests for
throughput (a common performance pattern) could trigger this by accident depending on
network timing/buffering, not just a deliberate attack.

Impact

Low-to-moderate: causes a hang on the affected connection (hasn't been confirmed to
propagate into the same connection-exhaustion pattern as the S7Comm issue above, but
given the pattern, an accumulation test seems worth running as a follow-up on your end
too).

Suggested fix

Ensure the Modbus TCP handler re-parses its receive buffer for additional complete ADUs
after processing one, rather than assuming one recv() cycle contains exactly one ADU.

---

3. Modbus server: stale/incorrect response for unassigned function codes

Summary

Requests using an unassigned "gap" function code (tested: 0x00, 0x09, 0x0A, 0x0D,
0x0E, and others in similar ranges) all return the exact same fixed response byte
string, regardless of the actual request sent or its Transaction Identifier. The
Transaction Identifier in the response doesn't match the request's TID at all, and the
returned "exception" function code corresponds to function code 0x28 — which none of
the test requests ever sent.

This looks like a fixed/leftover buffer being returned instead of a properly generated
Illegal-Function exception response.

Impact

Low — no crash, but a real spec violation. A client relying on TID matching to
correlate requests and responses (standard Modbus TCP practice) would misattribute this
response to whatever request happens to be pending with a matching (but coincidental)
TID, since the server's TID field doesn't reflect its actual value.

Suggested fix

Verify the exception-response code path for unassigned function codes actually
constructs a fresh response (echoing the request's real TID, and using
function_code | 0x80 with exception_code = 0x01) rather than returning a stale
buffer.

---

4. OPC-UA: anonymous sessions are elevated to the engineer/Admin role when a project has zero named users

Correction (2026-07-18): the version of this section I originally posted described
the per-role write check as "not running at all" when zero users are configured. That
was wrong, and I want to correct it rather than leave a misleading claim in the thread.
After reading the plugin source more carefully, the check does run — the real
mechanism is role elevation of anonymous sessions, and the issue is narrower (and
arguably intentional) than I first stated. Corrected details below.

Summary

The OPC-UA server enforces per-variable, per-role write permissions
(viewer/operator/engineer) at write time via a PreWrite callback
(callbacks.py::_on_pre_write), which resolves the connecting session's role and checks
that role's permission on the target node. That enforcement runs for anonymous sessions
too — so the earlier "no enforcement" framing was incorrect. The actual issue is which
role an anonymous session is assigned.

user_manager.py::_authenticate_anonymous deliberately elevates anonymous clients to the
engineer (Admin) role when the project has zero configured users:

if len(self.config.users) == 0:
    openplc_role = "engineer"
    asyncua_role = UserRole.Admin
else:
    openplc_role = "viewer"

The in-code docstring documents this as an intentional convenience ("no user model →
single-tenant → give anonymous the highest role so writes work without setting up
users"). The consequence is that, with zero users configured, an unauthenticated client
is evaluated as engineer, so it can write any variable whose engineer permission
includes write — typically the whole control surface, since engineer is the top role.

Reproduction

A/B test across recompiles of the same BOOL config (dummy1: viewer read-write;
dummy2/dummy3: viewer read-only, engineer read-write):

• ≥1 named user (UserManager initialized: 3 password users): anonymous resolves to
  viewer; writes to the viewer-read-only variables are explicitly denied and logged
  (DENY write for user anonymous (role: viewer) ...). Authenticated operator/
  viewer/engineer logins are all gated exactly per config.
• 0 named users (UserManager initialized: 0 password users): anonymous resolves to
  engineer, so writes to the engineer-writable variables succeed (logged as an ALLOW at
  debug level — hence no DENY line, which is what I earlier misread as "no
  enforcement"). Importantly, a variable set engineer: "r" is still denied in this
  state, and adding even one named user flips anonymous back to read-only viewer.

Impact

Conditional but realistic: a deployment that (a) enables the Anonymous auth method and
(b) has never created a named user — a plausible fresh-install/demo state — lets any
unauthenticated network client write every engineer-writable variable, defeating the
intent of the per-variable permission config for anyone in that state. It is not a
blanket failure, though: engineer: "r" variables stay protected, and
Username/certificate-only deployments are unaffected.

Suggested fix

Since the elevation appears intentional, this may be more of a fail-safe/hardening
question than a bug: when an Anonymous auth method is enabled and the user database
is empty, consider failing safe rather than open — e.g. deny writes for anonymous
sessions in that state, or emit a prominent startup warning that anonymous clients are
being granted engineer/Admin write access. That keeps the "drop in and read" convenience
without silently exposing the write surface.

CVSS 3.1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N for an affected deployment (unauthenticated
integrity impact on control data) — but the two preconditions (Anonymous enabled + zero
users) meaningfully narrow real-world exposure versus an unconditional bypass, and given
the behavior looks intentional I'd defer to you on whether this warrants a code change, a
documentation/hardening note, or a CVE.

---

Happy to share PoC scripts for any of these privately, and to help verify fixes once
available.

Researcher contact: Shad Malloy, shadmalloy3@gmail.com