Port 9443 – HTTPS Alt (WebSphere & Portainer Admin Consoles over HTTPS)

Port 9443 is the other common alternative HTTPS port — HTTP wrapped in TLS on a high, non-privileged number, distinct from its more famous sibling 8443. Two products own the default: IBM WebSphere Application Server serves its secure web container on 9443 (with the Integrated Solutions Console reachable at /ibm/console), and Portainer — the Docker/Kubernetes management UI — serves its whole web interface over HTTPS on 9443 out of the box. A grab-bag of appliances, SSL-VPN portals, and API gateways (some Fortinet, SonicWall, and vendor consoles) also publish management interfaces here. For a pentester an open 9443 is the same two-part target as any alt-HTTPS port: the TLS transport (certificate, protocols, ciphers) and the admin console or application behind it — and the console is almost always the bigger prize, because encrypting the tunnel does nothing to make the app inside it safe.

Why It’s Open

Port 9443 is open because a management console or application wanted HTTPS on a high port. The usual occupants:

• IBM WebSphere Application Server. 9443 is WebSphere’s default secure web-container port (WC_defaulthost_secure / HTTPS_TRANSPORT), serving deployed web applications over TLS. The Integrated Solutions Console (the admin console) lives at /ibm/console — its dedicated secure port defaults to the adjacent 9043, but on many installs the console and apps are reached over 9443 as well. An open 9443 answering with a WebSphere certificate or an /ibm/console login is a classic enterprise Java target.
• Portainer. Since HTTPS became the default (CE 2.9 / BE 2.10), Portainer serves its entire web UI over HTTPS on 9443, with legacy plaintext still available on port 9000. Portainer is a front-end to Docker, Docker Swarm, and Kubernetes, so whoever controls the 9443 console controls the container fleet behind it.
• Appliance, SSL-VPN, and API-gateway consoles. Various vendor appliances and gateways (some Fortinet, SonicWall, and other management/API consoles) publish an admin or API interface over HTTPS on 9443 instead of, or alongside, 443/8443. As always, fingerprint the exact product before assuming anything.

Because several different products default here, the first job on an open 9443 is to fingerprint what is answering, then assess that specific product — WebSphere, Portainer, and an appliance console are three very different attack surfaces.

Common Risks

The TLS wrapper on 9443 protects data in transit; it does not protect the console behind it. Most 9443 findings come from the application, not the crypto:

• Exposed management consoles that were meant to be internal. WebSphere’s /ibm/console, Portainer’s UI, and appliance admin portals are all interfaces vendors expect to be firewalled off the public internet. An internet-facing 9443 admin console is frequently the whole finding.
• Unauthenticated setup / admin-takeover windows. A freshly deployed Portainer on 9443 exposes an unauthenticated initialize-admin window — anyone who reaches it before a legitimate admin is created can claim the first admin account and own every environment Portainer manages (see CVE-2026-55761 below).
• WebSphere as a pivot to Java deserialization RCE. An open 9443 identifying a WebSphere instance points at the wider WebSphere management stack, whose SOAP and IIOP connectors on adjacent ports carry critical pre-auth deserialization RCEs — 9443 is often how you find the target before pivoting.
• Default, self-signed, or expired certificates. WebSphere and appliance consoles ship self-signed vendor certs that admins rarely replace, breaking TLS authentication and making on-path interception realistic.
• Weak TLS configuration. Older WebSphere and appliance builds still negotiate TLS 1.0/1.1, RC4, or 3DES. These transport-layer attacks are real but are the same cluster covered in depth on the port 443 page — on 9443 they usually just flag an unmaintained box.
• Encryption hides the payload. TLS terminates at 9443, so SQLi, SSRF, path traversal, and deserialization all ride inside the tunnel where a network IDS watching cleartext is blind.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Testing 9443 is a two-step: audit the TLS transport, then fingerprint and attack the console behind it.

Confirm the service, grab the certificate, and grade the crypto

nmap -sV -p 9443 --script ssl-cert,ssl-enum-ciphers <target>

ssl-cert prints the certificate (issuer, hostname, expiry — self-signed vendor certs stand out immediately) and ssl-enum-ciphers grades every protocol and ciphersuite A–F, so a single scan flags TLS 1.0, RC4, or 3DES.

Dig deeper into the TLS layer

sslscan <target>:9443
testssl.sh https://<target>:9443
openssl s_client -connect <target>:9443 -servername <target>

Fingerprint the console behind the TLS

curl -kvI https://<target>:9443/
whatweb https://<target>:9443
nmap -p 9443 --script http-title,http-headers,http-methods <target>

The -k flag tells curl to ignore the self-signed cert so you can read the real response. Read the Server: header, redirect target, and login-page branding to name the product.

Identify WebSphere

curl -k https://<target>:9443/ibm/console/

A Server: WebSphere Application Server/9.0 header, an /ibm/console login, or a default WebSphere welcome page confirms WebSphere. Note the version, then scan the adjacent connectors that carry the deserialization RCEs — the SOAP connector (default 8880) and the IIOP/ORB port (default 2809):

nmap -sV -p 2809,8880,9043,9443 <target>

Identify Portainer

curl -k https://<target>:9443/api/status
curl -k https://<target>:9443/api/system/status

Portainer’s status endpoint returns a JSON body with the exact Version. If the UI shows an “initialize admin” / first-run setup screen, the unauthenticated admin-init window is open — a critical, time-sensitive finding.

Log every weak protocol, self-signed cert, exposed console, and product/version you confirm so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The one CVE genuinely served on 9443 belongs to Portainer; WebSphere’s famous RCEs are served on adjacent connectors, and 9443 is how you find the WebSphere target rather than where you land the exploit. Every entry below is NVD-verified, with its true port scoped honestly:

• CVE-2026-55761 — Portainer unauthenticated admin-init (9443). During Portainer’s initial setup window, the /api/users/admin/init and /api/restore endpoints are reachable without authentication. An attacker who reaches a freshly deployed Portainer on 9443 before an administrator is created can create the first admin account or restore a malicious backup, gaining full administrative control over every Docker/Kubernetes environment Portainer manages. Affects Portainer CE 2.39.0–2.39.3 and 2.40.0–2.42.x (fixed in 2.39.4 and 2.43.0). CWE-287 (Improper Authentication); CVSS 4.0 7.1 (GitHub CNA), CVSS 3.1 5.9 (NVD).

WebSphere RCEs — real, critical, but NOT on 9443. These are Java deserialization bugs on WebSphere’s SOAP and IIOP connectors. 9443 (or the /ibm/console login it fronts) is how you identify a WebSphere box; the exploit lands on a different port. Included here so the pivot is obvious, with each true port labelled:

• CVE-2015-7450 — WebSphere Apache Commons Collections deserialization (SOAP, 8880). Unauthenticated RCE via a crafted serialized Java object hitting the InvokerTransformer gadget in Apache Commons Collections. The canonical exploit sends a SOAPAction: urn:AdminService request to the SOAP connector on port 8880, not 9443. CVSS 9.8 (CWE-502). Weaponised in Metasploit as exploit/windows/misc/ibm_websphere_java_deserialize and archived on Exploit-DB 41613.
• CVE-2020-4450 — WebSphere IIOP deserialization (IIOP/ORB, 2809). A pre-auth deserialization RCE in the IIOP protocol implementation of WebSphere 8.5 and 9.0 traditional. The attack targets the IIOP/ORB port (default 2809), not the 9443 HTTPS port. CVSS 9.8 (CWE-502).
• CVE-2023-23477 — WebSphere serialized-object RCE (IIOP, 2809). The same IIOP deserialization family as CVE-2020-4450: a crafted sequence of serialized objects yields remote code execution on WebSphere 8.5 and 9.0 traditional (fixed in 8.5.5.20 / 9.0.5.8). CVSS 9.8 (NVD) / 8.1 (IBM). Again, IIOP (2809), not 9443.

For an appliance or API-gateway console on 9443, the CVEs to check are those of that specific product and version — there is no generic “port 9443 CVE.”

Honest notes on scope (removed from the previous version of this page):

• CVE-2020-14882 and CVE-2019-2725 are Oracle WebLogic Server RCEs whose admin console defaults to 7001/7002, not 9443. The old “often on 9443” claim was wrong; both removed.
• CVE-2021-3449 is an OpenSSL TLS NULL-pointer DoS — a transport-library bug in the port 443 TLS cluster, not a 9443 service flaw. Removed.
• CVE-2023-3118 was labelled an “Apache Tomcat authentication bypass.” It is nothing of the sort — the NVD record is a reflected XSS in a WordPress “Export All URLs” plugin. Mislabelled and removed.
• CVE-2022-22963 is a Spring Cloud Function SpEL-injection RCE (the old page mislabelled it “Spring Cloud Gateway”), not a service that defaults to 9443. Removed. Verify every CVE against its NVD record and scope it to the actual product and port before trusting it.

Mitigation

• Keep management consoles off the public internet. WebSphere /ibm/console, Portainer, and appliance admin portals on 9443 should be reachable only from a management VLAN or over VPN. Firewall 9443 to trusted source IPs — most of the marquee risks stop mattering the moment the console isn’t internet-facing.
• Close Portainer’s setup window immediately. Never deploy Portainer where 9443 is internet-reachable before the first admin exists, update to a fixed build (2.39.4 / 2.43.0 or later), and initialise the admin account on a trusted network the instant the container comes up.
• Patch WebSphere and lock down its connectors. Apply current fix packs, and firewall the SOAP (8880) and IIOP (2809) connectors — not just 9443 — to management hosts, since that’s where the deserialization RCEs actually land.
• Fingerprint appliance consoles and patch the product behind the cert. Identify the exact vendor and version on 9443 and treat any internet-facing admin or SSL-VPN portal as a top-priority patch target.
• Fix the TLS config too. Serve TLS 1.2/1.3 only, drop RC4/DES/3DES, and replace self-signed vendor certs with trusted-CA certificates — aim for an A in sslscan/testssl.sh. (The full TLS-hardening checklist is on the port 443 page.)
• Enforce authentication and MFA on every console, and don’t rely on “it’s on 9443” as a security control — the port number is not access control.
• Don’t trust the tunnel to hide the app. TLS encrypts transit; it doesn’t stop SQLi, SSRF, or deserialization. Test the application on 9443 the same way you’d test anything on 8080 or 8443, and capture what you find in your pentest report.

Real-World Example

Portainer’s initial-setup flaw (CVE-2026-55761) is the cleanest illustration of why an open 9443 has to be treated as a live admin surface, not a “secure” high port. When a Portainer container first starts, it exposes an unauthenticated window in which /api/users/admin/init will create the first administrator account — the assumption being that the legitimate operator will hit it within moments on a trusted network. Deploy that container where 9443 is reachable from the internet and the assumption breaks: an attacker scanning for Portainer’s /api/status banner can race to /api/users/admin/init, create the admin account themselves (or restore a malicious backup via /api/restore), and instantly inherit control of every Docker and Kubernetes environment the Portainer instance manages — which usually means code execution across the whole container estate. The enterprise counterpart is WebSphere: mass scanners fingerprint 9443’s /ibm/console, then pivot to the SOAP (8880) or IIOP (2809) connector to fire a Java deserialization gadget (CVE-2015-7450, CVE-2020-4450). In both cases the TLS was fine and the port felt obscure — the console behind the cert was the whole attack.

FAQ

What is port 9443 used for?

Port 9443 is a standard alternative HTTPS port — HTTP over TLS on a high, non-privileged number. Its two headline occupants are IBM WebSphere Application Server, which uses 9443 as its default secure web-container port (with the /ibm/console admin console alongside), and Portainer, which serves its Docker/Kubernetes management UI over HTTPS on 9443 by default. Various appliance, SSL-VPN, and API-gateway consoles also publish here.

What is the difference between port 9443 and port 8443?

Both are alternative HTTPS ports and both carry HTTP over TLS — the difference is which products default to them. Port 8443 is the Apache Tomcat SSL connector plus Plesk, VMware, SonicWall, and Ivanti admin/SSL-VPN consoles. Port 9443 is led by WebSphere’s HTTPS web container and Portainer’s management UI. They’re siblings, so the workflow is identical: don’t assume the service — fingerprint whatever is actually answering, then check that product’s CVEs. The pure TLS-transport attacks (Heartbleed, POODLE, DROWN) belong to port 443 for both.

Does WebSphere use port 9443?

Yes. 9443 is WebSphere Application Server’s default secure web-container port (WC_defaulthost_secure), serving deployed applications over TLS, and the Integrated Solutions Console is reached at /ibm/console (its own secure default is the adjacent 9043, though it’s commonly fronted on 9443 too). Note that WebSphere’s critical deserialization RCEs are not served on 9443 — they hit the SOAP connector on 8880 and the IIOP/ORB port on 2809, so once 9443 tells you it’s WebSphere, scan those neighbours.

Why is port 9443 open on my server?

Almost always because a management console wanted HTTPS on a high port. The usual culprits are an IBM WebSphere Application Server, a Portainer container (which serves its UI on 9443 by default), or a vendor appliance/API-gateway console. Fingerprint it (curl -kvI https://<host>:9443/, curl -k https://<host>:9443/api/status, whatweb) to see exactly which product is listening.

How do I test port 9443 for vulnerabilities?

Audit the transport first — nmap -sV -p 9443 --script ssl-cert,ssl-enum-ciphers <host>, sslscan, or testssl.sh to grade the certificate and ciphers. Then fingerprint the console: curl -k https://<host>:9443/ibm/console/ for WebSphere and curl -k https://<host>:9443/api/status for Portainer. Identify the exact product and version, check that product’s CVEs, confirm whether any setup/admin-init window is open, and — for WebSphere — scan the adjacent SOAP (8880) and IIOP (2809) connectors.

Is port 9443 TCP or UDP?

TCP. HTTPS over TLS on 9443 is a TCP service, so scan it with nmap -sV -p 9443 (a TCP connect/SYN scan), not a UDP scan.

TL;DR

• Service: alternative HTTPS (HTTP over TLS) — IBM WebSphere Application Server’s default secure web port (/ibm/console admin console) and Portainer’s HTTPS management UI, plus assorted appliance and API-gateway consoles
• Default port: 9443/TCP (a sibling of 8443; the standard HTTPS port is 443, plaintext alt is 8080)
• Biggest risk: an internet-facing admin console — a Portainer setup window an attacker can claim (CVE-2026-55761) or a WebSphere instance you pivot from 9443 to its SOAP/IIOP deserialization RCEs (CVE-2015-7450, CVE-2020-4450, CVE-2023-23477) — encrypted transport doesn’t make the console safe
• Mitigation: keep consoles off the public internet and firewall 9443 (and WebSphere’s 8880/2809) to trusted IPs, close Portainer’s admin-init window and patch to a fixed build, replace self-signed certs, serve TLS 1.2/1.3 only, and test the app inside the tunnel