Skip to main content
9990

Port 9990WildFly 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.