Port 8181 – HTTP-Alt (Alternate HTTP App-Server & Framework Port)

Port 8181 has no single standard protocol — it is the alternate-HTTP port most associated with Java application servers and framework HTTP listeners. More specific defaults land here than on most alt-HTTP ports: the Apache Karaf OSGi runtime (and everything built on it — Apache ServiceMix, Talend/Fuse runtimes, Eclipse Jetty/OSGi web consoles) serves its web console on 8181 out of the box, the OpenDaylight SDN controller exposes its DLUX UI, RESTCONF northbound API, and API docs on 8181, and Oracle/Eclipse GlassFish and Payara open 8181 as their default HTTPS listener for deployed applications. Because so many different products bind here, the first job on an open port 8181 is not to attack a known protocol — it is to identify which framework is answering, then test that specific thing. Everything below is the methodology for doing that, plus the handful of CVEs that genuinely belong to services defaulting to 8181.

Sibling alternate-HTTP ports — fingerprint the actual service. Ports 8082 and 8099 are the same kind of generic “http-alt” listener: the port number tells you almost nothing, and the real work is identifying what is running before you test it. This page focuses on the app-server/framework cluster that most often lands on 8181; the linked siblings cover the same methodology for their own common occupants.

Why It’s Open

The dominant real-world use of port 8181 is a Java framework or application server exposing an admin/REST surface:

• Apache Karaf / Apache ServiceMix run their web console on http://<host>:8181/system/console by default, backed by an embedded Pax Web / Jetty container. Downstream products built on Karaf (Talend ESB Runtime, older Red Hat Fuse) inherit the same 8181 default.
• OpenDaylight (the ODL SDN controller, itself a Karaf distribution) serves its DLUX web UI at /dlux/index.html, its RESTCONF northbound API under /restconf (later /rests), and its API Explorer at /apidoc/explorer/index.html — all on 8181.
• GlassFish / Payara listen for HTTPS on 8181 by default (HTTP is on 8080, and the admin console is on 4848 — not 8181, a common misconception). A secure web app deployed to GlassFish answers on 8181.
• Generic and custom apps pick 8181 as an “alternate HTTP” port when 8080 is already taken, or as an alternate HTTPS port alongside 8443, so a plain, unbranded web app is also a real possibility.

An open 8181 therefore usually means a management console or REST API that was meant for an internal network and ended up reachable — the classic exposed-app-server pattern.

Common Risks

• Default framework credentials. Apache Karaf and its derivatives ship with the console login karaf / karaf; OpenDaylight historically shipped admin / admin. Left unchanged and exposed, these hand an attacker the full OSGi/SDN control plane.
• Authentication bypass in the framework. Some versions authenticate any credentials or expose unauthenticated endpoints (see the OpenDaylight CVEs below) — the login prompt is there but enforces nothing.
• OSGi / bundle deployment = code execution. The Karaf web console and shell let an authenticated user install bundles, run commands, and manage services — effectively remote code execution on the host once you are in.
• Cleartext HTTP. The Karaf/OpenDaylight console defaults to plain HTTP on 8181, so credentials and session tokens are sniffable on the wire; only GlassFish/Payara use 8181 for TLS.
• Information disclosure. API Explorers, RESTCONF schema dumps, Server: banners, and OSGi bundle listings reveal exact product, version, deployed apps, and internal topology — ideal fingerprinting for the next step.
• Directory traversal / path handling bugs. Server-side file-serving flaws (e.g. the GlassFish traversal below) let an attacker read arbitrary files through crafted HTTP requests to the listener.
• Control-plane takeover (SDN). On OpenDaylight, RESTCONF access means an attacker can rewrite flow rules and network configuration — compromising the whole software-defined network, not just one host.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The whole game on port 8181 is identifying the framework before you test it. Version-scan first, then branch on what the headers and paths tell you.

Detect the service and version

nmap -sV -p 8181 <target>
nmap -p 8181 --script=http-title,http-headers,http-auth,http-enum,ssl-cert <target>

Read the banner and decide HTTP vs HTTPS

# Plain HTTP (Karaf, ServiceMix, OpenDaylight)
curl -sI http://<target>:8181/

# TLS listener (GlassFish / Payara HTTPS)
curl -skI https://<target>:8181/

Fingerprint from the Server: header and any redirect: Server: Jetty(...) with an OSGi app points at Karaf/ServiceMix/OpenDaylight; a GlassFish/Grizzly banner over TLS points at GlassFish or Payara.

Probe the framework-specific paths

# Apache Karaf / ServiceMix / Jetty OSGi web console
curl -sI http://<target>:8181/system/console

# OpenDaylight DLUX UI, API Explorer, and RESTCONF
curl -sI http://<target>:8181/dlux/index.html
curl -sI http://<target>:8181/apidoc/explorer/index.html
curl -s  http://<target>:8181/restconf/modules

Test default and weak credentials

# Karaf console default karaf/karaf
curl -su karaf:karaf http://<target>:8181/system/console/bundles

# OpenDaylight default admin/admin against RESTCONF
curl -su admin:admin http://<target>:8181/restconf/operational/network-topology:network-topology

Check a GlassFish/Payara listener for the path-traversal bug

msfconsole -q
use auxiliary/scanner/http/glassfish_traversal
set RHOSTS <target>
set RPORT 8181
run

Log every open port 8181, the framework you positively identified, each default-credential hit, and any file or config you pulled back, so the evidence lands in the pentest report instead of a scratch terminal you will lose.

What to Look For

Known CVEs and Exploits

There is no generic “port 8181” CVE — the flaws that matter belong to whatever framework is listening. The genuinely 8181-relevant ones come from OpenDaylight (whose web/REST tier is served on 8181) and GlassFish (whose HTTPS listener defaults to 8181):

• CVE-2015-1778 — The custom authentication realm used by karaf-tomcat’s opendaylight realm in OpenDaylight before Helium SR3 authenticates any username and password combination. Because that realm guards the DLUX UI and RESTCONF API on 8181, an exposed pre-SR3 controller is effectively wide open. CVSS 3.0 9.8 (Critical).
• CVE-2015-1857 — The odl-mdsal-apidocs feature in OpenDaylight Helium before SR4 is missing AAA restrictions, letting a remote attacker reach the API Explorer / documentation surface (served on 8181) and obtain sensitive information about the controller’s models and endpoints. CVSS 3.1 5.3 (Medium).
• CVE-2017-1000028 — Oracle GlassFish Server Open Source Edition 4.1 directory traversal: a crafted HTTP GET reads arbitrary files. The flaw lives in GlassFish’s Grizzly HTTP handling, so it applies across its listeners — including the 8181 HTTPS listener GlassFish opens by default (the most-cited PoC targets the admin/HTTP listener). CVSS 3.x 7.5 (High). Weaponized as Metasploit auxiliary/scanner/http/glassfish_traversal and archived as Exploit-DB 39441.

Beyond CVEs, the highest-probability finding on 8181 is not a CVE at all but unchanged default credentials — karaf / karaf on Apache Karaf/ServiceMix consoles and admin / admin on OpenDaylight. These are design/deployment failures, not vulnerabilities with an NVD ID, but they are exploited far more often than any of the above.

What was corrected from the previous version of this page. The old stub framed 8181 as GlassFish’s administrative console — that is inaccurate: GlassFish’s admin console runs on 4848, and 8181 is its HTTPS application listener. Its non-CVE bullets (“GlassFish Default Credentials”, “Java Enterprise Application Vulnerabilities”, “Management Interface Exposure”) were generic placeholders with no CVE IDs and have been replaced with the honest default-credential risk above. The one real CVE it carried — CVE-2017-1000028 — was verified against NVD, confirmed to be genuine GlassFish, and kept with an accurate note on which listener it affects.

Mitigation

• Identify the real service first. You cannot secure port 8181 generically — it could be a Karaf console, an OpenDaylight controller, a GlassFish HTTPS listener, or a custom app. Fingerprint it, then harden the specific product.
• Change every default credential. Replace karaf / karaf, admin / admin, and any other shipped login before the service ever faces a network; add strong, unique passwords and, where supported, an IP allowlist on the console.
• Patch the framework. Update OpenDaylight past Helium SR3/SR4 (closes CVE-2015-1778 and CVE-2015-1857) and GlassFish past 4.1 (closes CVE-2017-1000028); track advisories for whatever exact product and version you found.
• Do not expose management surfaces to untrusted networks. Bind the Karaf/OpenDaylight console to localhost or a management VLAN, and put anything internet-facing behind a reverse proxy with authentication and TLS on 443 — the console defaults to cleartext HTTP on 8181.
• Turn off unused features. Disable the web console, API Explorer, and RESTCONF endpoints you do not need; each removed surface is one less thing to bypass.
• Firewall TCP/8181 to the hosts that legitimately need it, and audit cloud security groups and container port maps for an accidental 0.0.0.0:8181. Close it if nothing needs it, and rescan to confirm.

Real-World Example

OpenDaylight’s opendaylight authentication realm (CVE-2015-1778) is the cleanest illustration of why an open 8181 has to be identified and tested, not trusted. On any OpenDaylight controller before Helium SR3, the karaf-tomcat realm guarding the web tier on 8181 accepted any username and password — the DLUX login page and RESTCONF API looked protected but enforced nothing. An attacker who found an exposed controller could log straight into DLUX or drive RESTCONF to read and rewrite flow rules across the entire software-defined network: redirecting traffic, dropping flows, or reprogramming the fabric from a single unauthenticated HTTP request. Rated CVSS 9.8, it is the port-8181 lesson in miniature — the port number is mundane and shared by many unrelated frameworks, but the SDN control plane that happened to be listening on it was the real attack surface, and fingerprinting it was the whole job.

FAQ

What is port 8181 used for?

Port 8181 is a common alternate HTTP/HTTPS port for Java application servers and framework listeners. Apache Karaf, Apache ServiceMix, and OpenDaylight serve their web console and REST APIs on 8181 by default; GlassFish and Payara use it as their default HTTPS listener; and custom apps pick it when 8080 is taken. It has no single standard protocol, so the first step on an open 8181 is to identify which of these is actually running.

Why is port 8181 open on my server?

Almost always because a Java framework or app server is running. If you deployed Apache Karaf, ServiceMix, a Talend/Fuse runtime, an OpenDaylight controller, or GlassFish/Payara, one of them is listening on 8181 — usually a management console or REST API that was meant to stay on an internal network. If you cannot account for it, fingerprint the service before trusting it.

Is port 8181 HTTP or HTTPS?

Both, depending on the product. Apache Karaf, ServiceMix, and OpenDaylight serve plain HTTP on 8181 (their console credentials are sniffable unless you put TLS in front). GlassFish and Payara use 8181 specifically for HTTPS. Probe with both curl -sI http://<host>:8181/ and curl -skI https://<host>:8181/ to see which one answers.

What application server uses port 8181?

The strongest defaults are Apache Karaf and everything built on it (ServiceMix, Talend ESB, older Red Hat Fuse), the OpenDaylight SDN controller (a Karaf distribution), and GlassFish/Payara for HTTPS. Eclipse Jetty embedded in an OSGi runtime commonly ends up here too. Any of them may be behind an open 8181, which is why you fingerprint before you test.

How do I find out what’s running on my port 8181?

Fingerprint it: nmap -sV -p 8181 <host> for the version, then read the Server: header with curl -sI http://<host>:8181/. Check framework paths — /system/console (Karaf/OSGi), /dlux/index.html and /apidoc/explorer (OpenDaylight), and a TLS handshake with a GlassFish/Grizzly banner (GlassFish/Payara HTTPS). The path that responds tells you which product to test.

How do I secure or close port 8181?

Identify the framework, change every default credential (karaf/karaf, admin/admin), patch to a fixed version, and disable console/API surfaces you do not use. Keep management interfaces off untrusted networks — bind to localhost or a management VLAN, or front them with an authenticated TLS reverse proxy — and firewall TCP/8181 to the hosts that need it. If nothing needs it, stop the service and confirm with nmap -p 8181 <host>.

TL;DR

• Service: no single standard — most often a Java app-server or framework HTTP listener: Apache Karaf / ServiceMix web console, OpenDaylight SDN controller (DLUX / RESTCONF), or GlassFish/Payara HTTPS
• Default port: 8181/TCP (plain HTTP for Karaf/OpenDaylight; HTTPS for GlassFish/Payara)
• Biggest risk: an exposed framework console with default or bypassable auth (karaf/karaf, admin/admin, OpenDaylight CVE-2015-1778) leading to OSGi/SDN control-plane takeover — identify what’s answering before you trust it
• Mitigation: fingerprint the real service, change default credentials, patch (OpenDaylight past Helium SR3/SR4, GlassFish past 4.1), keep consoles off untrusted networks behind authenticated TLS, and firewall 8181 if nothing needs it