Port reference
Port 1099 (TCP) – Java RMI Registry
Java Remote Method Invocation registry — name service that binds remote Java objects for client lookup.
Default state
Open on Java applications and middleware (app servers, JMX agents) exposing RMI endpoints, frequently without authentication.
Common attacks
- Insecure deserialization RCE via gadget chains (ysoserial)
- Registry enumeration and remote object dumping
- JMX/RMI exploitation for remote code execution
- Codebase/classloader abuse to load attacker classes
Hardening
- Do not expose RMI/JMX to untrusted networks
- Require authentication and TLS on JMX/RMI endpoints
- Patch the JVM and apply deserialization allowlists/filters
- Disable remote codebase loading (java.rmi.server.useCodebaseOnly=true)
- Firewall 1099 and the dynamic RMI object ports
nmap snippet
nmap -p1099 --script rmi-dumpregistry,rmi-vuln-classloader <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 1099?
Port 1099 is the default for the Java RMI Registry, a name service in Java's Remote Method Invocation framework. Clients query the registry to look up remote objects by name and obtain stubs that proxy method calls to a server JVM. It underpins distributed Java applications and is commonly reached through JMX for remote management of app servers and middleware.
Why it matters for security
RMI's core risk is insecure deserialization. The protocol deserializes Java objects supplied by the caller, so if a vulnerable gadget class sits on the server's classpath, an attacker can craft a payload that runs arbitrary code. Many RMI and JMX endpoints are exposed without authentication, turning a simple registry lookup into a pre-auth RCE. Legacy support for remote codebase loading compounds the exposure.
How it's attacked
Attackers enumerate the registry to dump bound remote objects, then deliver a ysoserial gadget chain over RMI to trigger deserialization and execute code. Exposed JMX services are hit the same way, and where remote codebase loading is enabled, the attacker forces the JVM to load malicious classes from a URL they control.
Hardening checklist
Keep RMI and JMX off untrusted networks, and require authentication and
TLS on remote management endpoints. Patch the JVM and apply
deserialization filters/allowlists to reject dangerous classes. Disable remote
codebase loading with java.rmi.server.useCodebaseOnly=true, and firewall 1099
plus the dynamic RMI object ports. Use the nmap snippet above to enumerate the
registry and test classloader exposure on hosts you are authorized to assess.
Related ports
Frequently asked questions
- Why is the RMI registry on port 1099 risky?
- RMI deserializes attacker-controlled objects. With a vulnerable gadget on the classpath, a single crafted call yields remote code execution, often with no authentication.
- Is port 1099 related to JMX?
- Yes. JMX commonly uses RMI for remote management, with the registry on 1099. Exposed JMX/RMI is a well-known path to deserialization RCE.