Skip to main content
9990

Port 9990 – WildFly Management

TCP

Port 9990 is the WildFly (formerly JBoss AS) management console and CLI port. The admin console on port 9990 provides full application server control – deploying WARs, configuring datasources, managing security realms. Exposing port 9990 enables full server compromise via deployment of malicious applications.

Port Number

9990

Protocol

TCP

Service

WildFly / JBoss Management Console

Range

IANA Registered (1024–49151)

Description

WildFly management on port 9990 serves both the web-based admin console (http://host:9990/console) and the native management CLI (jboss-cli.sh --connect). Through this port, administrators deploy and undeploy applications, configure JDBC datasources, manage JMS queues, and control clustering. Port 9990 with default or weak credentials is a direct path to remote code execution – an attacker deploys a malicious WAR file and gains OS-level access as the WildFly process user. Default WildFly installations require add-user.sh to create a management user before remote access works, but many development instances skip this step. In production: use strong management credentials, bind port 9990 to a management interface (127.0.0.1 or dedicated management NIC), and restrict via firewall.

Security risks

  • 1CVE-2017-12149 – JBoss 5.x/6.x deserialization RCE via /invoker/readonly endpoint. Unauthenticated remote code execution as the application server user. CVSS 9.8.
  • 2WAR deployment as RCE – any authenticated user with deployer role can upload a malicious WAR (e.g., cmd.war webshell) gaining OS-level command execution as the WildFly process user.
  • 3CVE-2023-26464 – Log4j-related DoS in WildFly logging subsystem. Crafted log messages via management interface cause OutOfMemoryError.
  • 4Default credential exposure – development instances often skip add-user.sh, leaving management accessible with no credentials or well-known defaults (admin/admin).
  • 5JMX invoker exposure – older JBoss versions expose JMX MBeans through the management port, allowing arbitrary method invocation on server components.

Firewall guidance

Bind management interface to 127.0.0.1 in standalone.xml (<inet-address value="127.0.0.1"/> under management interfaces). Never expose port 9990 to the network. For remote admin, use SSH tunnel or the CLI over a management VPN. In Kubernetes, do not include port 9990 in Service definitions.

Diagnosis commands

Detect WildFly version from the admin console login page

shell
curl -s http://target:9990/console/ | grep -i wildfly

Test for default/weak management credentials

shell
curl -s http://target:9990/management --digest -u admin:admin

List deployed applications via CLI

shell
jboss-cli.sh --connect controller=localhost:9990 --command='ls deployment'

Check for JBoss deserialization RCE vulnerability

shell
nmap --script=http-vuln-cve2017-12149 -p 9990 target

Usage examples

Port 9990 – WildFly Management
shell
jboss-cli.sh --connect controller=localhost:9990
http://localhost:9990/console/ (admin web UI)
add-user.sh -u admin -p password -g ManagementRealm

Common services on this port

WildFlyJBoss EAPJBoss AS 7.xKeycloak (embedded WildFly)

Related ports

History

JBoss AS used port 8080 for both application and admin traffic until JBoss 7 (2011) split management to port 9990. WildFly (the JBoss AS rebrand in 2013) kept this convention. The split was a security improvement – separating admin from application traffic enables network-level isolation that was impossible when both shared port 8080.

FAQ

How do I secure WildFly management on port 9990?

Three steps: 1) Bind to 127.0.0.1 in standalone.xml management interfaces section. 2) Run add-user.sh to create strong management credentials with minimal roles. 3) Enable management-https (port 9993) with a proper certificate if remote access is unavoidable. Never expose 9990 over plain HTTP on a network.

Can an attacker deploy code through port 9990?

Yes – this is the primary risk. Any user with the deployer management role can upload a WAR file containing arbitrary code. The WAR executes as the WildFly process user (often root in misconfigured containers). CVE-2017-12149 also allows unauthenticated RCE on older JBoss versions without needing credentials at all.