Port 4840 – OPC UA (Open Platform Communications Unified Architecture)

Port 4840 is the default port for OPC UA (Open Platform Communications Unified Architecture), the modern, vendor-neutral protocol that has become the interoperability backbone of Industry 4.0 and the Industrial Internet of Things (IIoT). OPC UA is the successor to the old Windows-and-DCOM-bound OPC Classic, and it is how PLCs, SCADA systems, MES, and historians from different vendors exchange process data on a plant floor. An OPC UA server exposes its data as a browsable address space — a tree of nodes, variables, and methods — and clients connect over the binary opc.tcp://<host>:4840 transport to browse it, read and write values, and call methods. Crucially, OPC UA can be secure: the spec has built-in user authentication and message signing/encryption via SecurityPolicies. The catch is that all of that is optional, and an enormous number of servers on 4840 are deployed with SecurityPolicy=None and Anonymous access enabled — so anyone who can reach the port can drive the process.

Why It’s Open

OPC UA is designed to be reached. It exists specifically so that a SCADA/HMI, a MES, a data historian, or a cloud/IIoT gateway can pull live data out of PLCs and controllers and push commands back — across vendors and across the IT/OT boundary. Port 4840/TCP is the IANA-registered default for the opc.tcp binary protocol (some products also offer OPC UA over HTTPS/WebSockets on other ports), so wherever OPC UA is in use, something is usually listening on 4840.

You will find it embedded in PLC firmware (Siemens, Beckhoff, WAGO, B&R), in dedicated OPC servers and aggregators (Kepware KEPServerEX, Softing, Prosys, Unified Automation-based products), and in the open-source open62541 stack baked into countless gateways and appliances. Because OPC UA was meant to replace brittle, DCOM-tunnelled OPC Classic and simplify cross-vendor integration, it is deliberately routable and firewall-friendly — which is exactly what makes an exposed 4840 dangerous. Like Modbus on 502, SNMP on 161, or MQTT on 1883, the port is open because a control system genuinely needs to talk; the problem is who else can reach it and whether the optional security was ever turned on.

Common Risks

• SecurityPolicy=None + Anonymous access — the dominant risk. OPC UA’s authentication, signing, and encryption are optional SecurityPolicies, and in the field they are very frequently left off. A server that offers a None endpoint and accepts an Anonymous user token lets any client that reaches 4840 connect with no credentials at all — no password, no certificate.
• Full address-space exposure. Once connected, an attacker can browse the entire node tree, enumerating every variable, object, and method the server exposes — effectively a live map of the process and its tags.
• Unauthenticated read/write of live values. If nodes are writable (a common default), the attacker can change setpoints, tags, and outputs — directly manipulating the physical process — and can call exposed methods, which may include control actions.
• Certificate and trust misconfiguration. Even where a secure policy is nominally used, servers are often set to auto-accept or trust any client certificate, or ship with weak/self-signed certs, collapsing the authentication the policy was supposed to provide.
• Information disclosure. The GetEndpoints handshake reveals the server’s application URI, product/vendor, hostname, and the full list of endpoints and their SecurityPolicies before any authentication — ideal reconnaissance for choosing an attack.
• Stack implementation bugs. OPC UA stacks (open62541, the OPC Foundation .NET Standard stack, and various vendor stacks) have carried real, remotely triggerable denial-of-service flaws in their message parsing (see CVEs below) — a hang or crash of an OPC server can blind or stall the systems that depend on it.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

OPC UA speaks a binary framed protocol over opc.tcp — a session opens with a HEL (Hello) message that the server answers with an ACK, so a plain nc/telnet banner grab tells you almost nothing. The productive path is a version scan to confirm the service, then a real OPC UA client to discover endpoints and (if None/Anonymous is allowed) browse the address space.

Detect the service and version

Nmap does not ship a dedicated OPC UA NSE script, but its service-probe database recognises the opc-ua-tcp protocol, so a version scan is the right first move:

nmap -sV -p 4840 <target>

Discover endpoints and SecurityPolicies (the key check)

The OPC UA GetEndpoints request returns every endpoint URL, its SecurityPolicy and MessageSecurityMode, and which user-token types (including Anonymous) are accepted — all before authentication. The FreeOpcUa / asyncua Python library (pip install asyncua) ships console tools for exactly this:

# List endpoints, security policies, and accepted user tokens
uadiscover opc.tcp://<target>:4840

Look for any endpoint advertising SecurityPolicy#None and an Anonymous user identity token — that is the open-door condition.

Browse the address space and read values (if None/Anonymous)

# Walk the node tree
uabrowse -u opc.tcp://<target>:4840

# Read a specific node's value
uaread -u opc.tcp://<target>:4840 -n "ns=2;i=2"

# List a node's children
uals -u opc.tcp://<target>:4840 -n "i=85"

Interactive client

A graphical client makes address-space review far faster. UaExpert (the free Unified Automation client) and the FreeOpcUa GUI (pip install opcua-client, launched with opcua-client) both connect to opc.tcp://<target>:4840, show endpoints and their security, and browse/read/write nodes. On the offensive side there is no OPC UA module in the upstream Metasploit framework; the community COMSYS/msf-opcua project provides third-party modules, and wavestone-cdt/opcua-scan (built on it) automates discovery — treat both as external tools, not shipped ones.

Capture every open port 4840, the endpoint/SecurityPolicy findings, and any node you could read or write, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Be honest about where the risk lives: on port 4840 the dominant issue is a design/deployment choice — SecurityPolicy=None with Anonymous access — not a memory-corruption CVE. There is no “OPC UA RCE” that pops every server; the protocol lets you in through the front door when security is left off. That said, the OPC UA stacks themselves have carried genuine, remotely triggerable denial-of-service bugs in their message parsing. The following are verified against their NVD records and scoped to real OPC UA implementations:

• CVE-2022-25761 — open62541 (before 1.2.5, and 1.3-rc1 before 1.3.1). The stack places no limit on the number of received chunks, so a remote attacker can send an unbounded stream of huge chunks (e.g. 2 GB each) without ever sending the final closing chunk, exhausting memory and causing denial of service. CVSS 3.1 7.5.
• CVE-2022-29862 — OPC UA .NET Standard Stack (1.04.368 and earlier). A crafted message triggers an infinite loop (CWE-835), hanging the application. CVSS 3.1 7.5.
• CVE-2022-29863 — OPC UA .NET Standard Stack (1.04.368 and earlier). A crafted message triggers excessive memory allocation, crashing the server (denial of service). CVSS 3.1 7.5.
• CVE-2021-27432 — OPC Foundation UA .NET Standard (prior to 1.4.365.48) and OPC UA .NET Legacy. Uncontrolled recursion (CWE-674) lets an attacker trigger a stack overflow and crash the service. CVSS 3.1 7.5.

Every one of these is a denial-of-service class bug — an attacker can hang or crash a reachable OPC server, which in an OT context can blind an HMI or stall data collection, but none of them is a magic remote shell. The realistic full-control path on this port is the misconfiguration: reach a None/Anonymous endpoint, browse, and write. No wrong-service or fabricated CVEs were carried over from a prior stub — this page was created fresh with only NVD-verified, OPC UA-scoped entries.

Mitigation

• Turn the built-in security on. Require a real SecurityPolicy (Basic256Sha256 or better) with MessageSecurityMode SignAndEncrypt, and remove or disable the None endpoint so no unencrypted, unsigned channel is offered at all.
• Kill Anonymous access. Require certificate or username/password user tokens; disable the Anonymous identity token on production servers.
• Manage certificates properly. Do not auto-accept or blindly trust client certificates — use an explicit trust list (or a proper PKI), reject self-signed/expired certs, and rotate keys.
• Least privilege on the address space. Make nodes read-only unless a write is genuinely required, restrict which methods are exposed, and scope permissions per user/role rather than granting everything to every session.
• Segment OT from IT. Keep OPC UA on a control network behind a firewall; if data must cross to IT/cloud, broker it through an OPC UA aggregator or data diode rather than exposing 4840 directly. Never publish 4840 to the internet.
• Patch the stack. Keep open62541, the OPC Foundation .NET Standard stack, and vendor OPC UA stacks current to close the DoS bugs above.
• Monitor and firewall TCP/4840 to the specific SCADA/MES/historian hosts that need it, and rescan to confirm nothing else can reach it.

Real-World Example

The canonical OPC UA lesson has two halves. The everyday reality is what internet scans keep finding: large numbers of OPC UA servers reachable on 4840 that advertise a SecurityPolicy=None endpoint and accept Anonymous sessions — meaning any connecting client can browse the full address space and, where nodes are writable, change live process values without a single credential. That is not an exotic exploit; it is the protocol’s optional security simply left off.

The other half is that the stacks are provably attackable when researchers focus on them. At Pwn2Own Miami, the ICS-focused contest, OPC UA implementations (including the OPC Foundation’s .NET Standard stack and Unified Automation-based products) have been repeated targets, and competitors demonstrated denial-of-service and other flaws against them — the same class of parsing bugs catalogued in the CVEs above, and the work security teams like Claroty’s Team82 have detailed across multiple vendor OPC UA stacks. The takeaway for a pentest: on port 4840, first check whether security was ever enabled — because far more often than a stack 0-day, the finding is simply an open None/Anonymous endpoint handing you the process, and it belongs, with the exact endpoint and the values you could reach, in the pentest report.

FAQ

What is port 4840 used for?

Port 4840 is the default port for OPC UA (Open Platform Communications Unified Architecture), the vendor-neutral industrial protocol used to exchange process data between PLCs, SCADA/HMI systems, MES, historians, and IIoT gateways. Clients connect over the opc.tcp://<host>:4840 binary transport to browse a server’s address space, read and write variables, and call methods. It is the modern successor to the old, DCOM-bound OPC Classic.

Is OPC UA secure by default?

It can be secure but often isn’t. OPC UA has built-in user authentication and message signing/encryption via SecurityPolicies, but those are optional. In the field a great many servers are deployed with SecurityPolicy=None and Anonymous access enabled, which lets anyone who can reach port 4840 connect with no credentials and interact with the process. Security must be explicitly configured on.

What can an attacker do on an open port 4840?

If the server offers a None/Anonymous endpoint, an attacker can open a session, browse the entire node tree (enumerating every variable and method), read live values, and — if nodes are writable — change setpoints and outputs or call control methods, directly manipulating the physical process. Even secured servers can leak endpoint and product details through the pre-authentication GetEndpoints handshake.

Does OPC UA have known CVEs?

Yes, but they are almost all denial-of-service bugs in the OPC UA stacks rather than remote-code-execution flaws. Verified examples include CVE-2022-25761 (open62541 chunk exhaustion), CVE-2022-29862 and CVE-2022-29863 (OPC UA .NET Standard Stack infinite loop / memory exhaustion), and CVE-2021-27432 (OPC Foundation UA .NET Standard uncontrolled recursion). On this port the bigger real-world risk is the None/Anonymous misconfiguration, not a CVE.

How do I check whether my OPC UA server is exposed?

Run nmap -sV -p 4840 <host> to confirm the service, then use an OPC UA client — uadiscover opc.tcp://<host>:4840 (from the Python asyncua package) or the free UaExpert GUI — to list the endpoints. If any endpoint shows SecurityPolicy#None or accepts an Anonymous user token, or if you can browse and read nodes without credentials, it is exposed and needs the security policy and authentication turned on.

How do I secure port 4840?

Require a real SecurityPolicy with SignAndEncrypt, remove the None endpoint, disable Anonymous access, and enforce certificate or username/password authentication with a proper trust list. Make nodes read-only unless a write is needed, keep OPC UA on a segmented OT network behind a firewall (never on the public internet), broker any IT/cloud access through an aggregator, patch the stack, and restrict TCP/4840 to the hosts that genuinely need it.

TL;DR

• Service: OPC UA (Open Platform Communications Unified Architecture) — vendor-neutral industrial interoperability over opc.tcp, the Industry 4.0 / IIoT data backbone
• Default port: 4840/TCP
• Biggest risk: servers deployed with SecurityPolicy=None and Anonymous access — reach 4840 and you can browse the address space, read/write values, and call methods with no credentials; stack bugs add DoS on top
• Mitigation: enforce a real SecurityPolicy with SignAndEncrypt, disable the None endpoint and Anonymous access, manage certificates, make nodes least-privilege, segment OT from IT, patch the stack, and firewall TCP/4840 to only the hosts that need it

OPC UA increasingly sits above the same devices that speak lower-level fieldbus protocols, so on an OT engagement review EtherNet/IP on port 44818 and Modbus on port 502 alongside it — a modern plant frequently exposes all three.