Port 9093 – Apache Kafka (Secured TLS/SASL Broker Listener, also Alertmanager)

Port 9093 is most often a secured Apache Kafka broker listener. Kafka’s plaintext default is 9092; by long-standing convention teams put a second, encrypted or authenticated listener on 9093 — the SSL:// or SASL_SSL:// listener that clients and other brokers use for TLS-encrypted, authenticated traffic. So an open 9093 usually means “the Kafka broker’s secure endpoint.” But there’s one genuinely common collision to rule out first: Prometheus Alertmanager binds 0.0.0.0:9093 by default, so on a monitoring host an open 9093 is just as likely to be Alertmanager’s HTTP API and UI. The two are trivially distinguished — Alertmanager answers plain HTTP on /api/v2/status, Kafka speaks its own binary wire protocol — and the first job on an open 9093 is to figure out which one you’re looking at before you test it.

Why It’s Open

The dominant real-world use of port 9093 is a secured Apache Kafka listener. Kafka is a distributed event-streaming platform; a broker advertises one or more listeners, each a protocol://host:port tuple. The plaintext listener sits on 9092 by default, and when operators add TLS or SASL they conventionally bind the secured listener to 9093 (and sometimes 9094 for a third, e.g. SASL_PLAINTEXT internal traffic). On 9093 you’ll typically find SSL (mutual or server-side TLS) or SASL_SSL (SASL authentication over TLS), used both for client→broker producer/consumer traffic and for inter-broker replication. Because the port is meant to be the hardened one, finding it open with authentication or encryption not actually enforced is a common and high-value misconfiguration. Kafka fills the same broker-shaped slot in an architecture as classic message queues like RabbitMQ’s AMQP listener on 5672 and ActiveMQ’s OpenWire transport on 61616, and in classic (pre-KRaft) mode it keeps its cluster metadata and controller state in Apache ZooKeeper on 2181 — so an exposed broker often travels with an exposed coordination layer.

Port 9093 is also the Prometheus Alertmanager default. Alertmanager — the component that deduplicates, groups, and routes alerts fired by Prometheus on 9090 — listens on 9093 for its web UI and its /api/v2/* REST API out of the box. On monitoring infrastructure this collision is real and frequent, which is why identifying the service (Kafka broker vs. Alertmanager) is step one rather than an afterthought. Occasionally 9093 is also picked by other custom or enterprise services, so don’t assume — fingerprint it.

Common Risks

• Exposed Kafka broker with no authentication or ACLs. This is the headline risk. Kafka does not require authentication by default, and an internet- or LAN-reachable broker with no SASL/mTLS and no ACLs lets anyone list metadata, read every topic (data exfiltration of whatever the business streams — orders, events, PII, logs), write/inject messages into any topic, and tamper with consumer-group offsets to replay or skip records.
• PLAINTEXT listener misconfiguration. If 9093 was meant to be SSL/SASL_SSL but is actually serving a PLAINTEXT listener (or TLS is present but client-auth isn’t enforced), the “secure” port isn’t secure — traffic is sniffable and any client can connect. A weak or expired TLS config, or ssl.client.auth=none where mutual auth was intended, has the same effect.
• Metadata and topic-name disclosure. Even without reading message payloads, an unauthenticated metadata request leaks the full topic list, partition layout, broker hostnames/IPs, and cluster ID — a map of the data pipeline and its internal hosts, and a shortlist of which topics are worth targeting.
• Consumer-group and offset tampering. Write access lets an attacker commit bogus offsets, delete consumer groups, or flood partitions, disrupting downstream processing (a denial-of-service against the pipeline, not just the broker).
• Unauthenticated Prometheus Alertmanager (the collision case). If 9093 is Alertmanager and it’s exposed without auth, an attacker can read alert contents and routing config (which can embed secrets like webhook URLs, API tokens, and SMTP creds), create silences to suppress alerts during an attack, inject fake alerts, and abuse webhook/receiver configuration to reach internal services (SSRF-style).

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 9093 is identifying which service answers — Kafka broker or Alertmanager — before you test it. Start with a version scan, then branch.

Detect the service and version

nmap -sV -p 9093 <target>

Nmap’s service probes will usually label 9093 as kafka or flag an HTTP service. Note there is no dedicated Kafka NSE script shipped with Nmap — don’t reach for a kafka-* script, it doesn’t exist. Use -sV and the tools below instead.

Grab a raw banner / decide HTTP vs. binary

nc -nv <target> 9093

A Kafka broker speaks a binary wire protocol and won’t return readable text; an HTTP service (Alertmanager) will respond to an HTTP request. Confirm which:

Distinguish Prometheus Alertmanager

curl -s http://<target>:9093/api/v2/status

If you get JSON back describing an Alertmanager cluster (versionInfo, cluster, config), it’s Alertmanager, not Kafka — enumerate its /api/v2/alerts, /api/v2/silences, and /#/status (which renders the loaded config, potentially exposing receiver secrets). If the request hangs or returns garbage, you’re almost certainly looking at a Kafka broker.

List Kafka metadata with kcat (formerly kafkacat)

# Plaintext / no-auth broker — lists brokers, topics, partitions
kcat -b <target>:9093 -L

A successful metadata dump against a broker that should be secured is the finding: it means the listener accepts unauthenticated connections. If the broker requires TLS, add the TLS options:

# TLS listener (server-side TLS, no client cert)
kcat -b <target>:9093 -X security.protocol=SSL -L

Inspect the TLS listener

openssl s_client -connect <target>:9093 -servername <target>

Read the certificate (issuer, CN/SAN, expiry, self-signed?), the negotiated protocol/cipher, and — importantly — whether the server requests a client certificate. No client-cert request on a listener that was supposed to enforce mTLS is a misconfiguration worth flagging.

Log every open port 9093, the service you positively identified, any topic or metadata you could read without credentials, and the TLS posture, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no generic “port 9093” CVE — what matters is the product answering on it. For Apache Kafka the most serious design flaw and the notable named bugs are:

• CVE-2023-25194 — SASL JAAS JndiLoginModule unsafe deserialization in the Apache Kafka Connect API (versions 2.3.0 through 3.3.2). An authenticated operator who can set the sasl.jaas.config property to com.sun.security.auth.module.JndiLoginModule can point the connector at a malicious LDAP/JNDI server and trigger a Java deserialization gadget chain, achieving remote code execution. CVSS 8.8. Scope it correctly: the direct attack surface is the Kafka Connect REST API (its own port, typically 8083), not the broker listener on 9093 — but because it turns on attacker-controlled SASL JAAS config, it’s the CVE that matters most anywhere Kafka SASL configuration is exposed.
• CVE-2022-34917 — Unauthenticated memory-allocation denial of service in Apache Kafka (2.8.0–2.8.1, 3.0.0–3.0.1, 3.1.0–3.1.1, 3.2.0–3.2.1). Malicious unauthenticated clients can make brokers allocate huge amounts of memory, hitting OutOfMemoryException and crashing — directly relevant to a broker listener reachable on 9093. CVSS 7.5.
• CVE-2021-38153 — Timing side-channel in Apache Kafka (2.0.0 through 2.8.0). Some components validate a password or key with Arrays.equals, whose non-constant-time comparison leaks timing information that makes brute-forcing SASL/SCRAM credentials more feasible — relevant to the authenticated listener you’d expect on 9093. CVSS 5.9. Fixed in 2.8.1 / 3.0.0.

If 9093 turns out to be Prometheus Alertmanager, the verified named bug is:

• CVE-2023-40577 — Stored XSS in Prometheus Alertmanager (0.25.0 and earlier, fixed in 0.25.1). An attacker able to POST to /api/v1/alerts can store JavaScript that executes in the browser of anyone viewing the Alertmanager UI. CVSS 5.4.

Corrections to the previous version of this page. It listed CVE-2023-1370 as a “Prometheus Alertmanager SSRF” — that CVE is actually an uncontrolled-recursion stack-overflow DoS in the json-smart JSON library, nothing to do with Alertmanager or SSRF, and has been removed. It also mislabeled CVE-2022-34917 as a “privilege escalation” (it’s an unauthenticated OOM DoS) and CVE-2021-38153 as a “client deserialization RCE” (it’s a credential timing side-channel); both descriptions have been corrected above. Finally, the old page attached the generic Log4j bugs CVE-2021-44228 and CVE-2021-45046 to this port — Kafka ships with the Log4j 1.x / reload4j logging stack, which is not vulnerable to Log4Shell, and neither CVE is scoped to a service on 9093, so both were removed. Verify every CVE against its NVD record and scope it to the actual product before trusting it.

Mitigation

• Identify the real service first. You can’t harden port 9093 generically — a Kafka broker and Alertmanager need completely different controls. Fingerprint it (nmap -sV, curl /api/v2/status), then secure the specific thing behind it.
• If it’s a Kafka broker: require authentication and enforce ACLs. Configure SASL_SSL (or mutual TLS) on the 9093 listener, set allow.everyone.if.no.acl.found=false, and grant per-topic/per-group ACLs so anonymous clients get nothing. Confirm the listener is genuinely SSL/SASL_SSL, not a stray PLAINTEXT, and that ssl.client.auth=required where you intended mTLS.
• Encrypt properly. Use current TLS with valid, non-self-signed certificates and modern ciphers; encrypt inter-broker traffic too, not just client traffic. Terminate real TLS on the secured listener rather than trusting network location.
• If it’s Alertmanager: put it behind authentication. Alertmanager has no built-in auth — front it with a reverse proxy that enforces authentication (and TLS), keep its /api/v2/* and UI off the public internet, and store receiver secrets outside the config where possible. Patch to 0.25.1+ for the stored-XSS fix.
• Patch. Keep Kafka off the versions affected by CVE-2022-34917 and CVE-2021-38153, and — critically — lock down or patch any Kafka Connect deployment (CVE-2023-25194) and restrict which SASL JAAS modules connectors may configure.
• Firewall 9093 to the brokers, clients, and monitoring hosts that actually need it, and audit cloud security groups and container mappings for an accidental 0.0.0.0:9093. Close it and rescan if nothing legitimately needs external access.

Real-World Example

Exposed Kafka brokers are not hypothetical: internet-wide scans (Shodan/Censys) routinely turn up tens of thousands of Kafka brokers reachable from the public internet, a large share of them accepting unauthenticated connections because Kafka ships with no auth enabled and allow.everyone.if.no.acl.found defaults to permitting access when no ACLs are set. Against one of those, a single kcat -b <target>:9093 -L returns the full topic list, partition layout, and broker hostnames — and because there are no ACLs, the same anonymous connection can then consume every topic (reading whatever the organization streams through Kafka, from clickstream to payment events to internal logs) and produce forged messages into any topic. No CVE, no exploit chain — just a broker that was deployed with the defaults and reachable from somewhere it shouldn’t be. It’s the port-9093 lesson in miniature: the danger usually isn’t a memory-corruption bug, it’s a “secure” listener that never had authentication or ACLs turned on.

FAQ

What is port 9093 used for?

Port 9093 is most commonly the secured listener of an Apache Kafka broker — the TLS/SSL or SASL_SSL endpoint that sits alongside Kafka’s plaintext default of 9092 and carries authenticated, encrypted producer, consumer, and inter-broker traffic. It’s also the default port for Prometheus Alertmanager’s web UI and REST API, which is a common collision on monitoring hosts. On an open 9093, identify which of the two is running before testing.

Is 9093 Kafka or Alertmanager?

Both use it, so check. A Kafka broker speaks a binary wire protocol and won’t answer a plain HTTP request; Prometheus Alertmanager answers HTTP — curl http://<target>:9093/api/v2/status returns JSON describing an Alertmanager cluster. If that request returns Alertmanager data it’s Alertmanager; if it hangs or returns non-HTTP bytes, it’s almost certainly Kafka. nmap -sV -p 9093 and kcat -b <target>:9093 -L (which lists Kafka metadata) also disambiguate.

Why is port 9092 vs 9093 for Kafka?

Kafka brokers advertise one listener per security protocol. By convention the PLAINTEXT listener goes on 9092 and a secured listener (SSL or SASL_SSL) goes on 9093 (a third, often SASL_PLAINTEXT for internal traffic, sometimes on 9094). The numbers are conventions set in the broker’s listeners/advertised.listeners config, not hard requirements — but 9093 as “the secure Kafka port” is near-universal.

Is it dangerous to expose port 9093?

It can be. Kafka requires no authentication by default and permits access when no ACLs are set, so an exposed broker on 9093 without SASL/mTLS and ACLs lets anyone read and write every topic — a direct data-exfiltration and message-injection risk. An exposed Alertmanager on 9093 has no built-in auth either, leaking alert config (which can contain secrets) and allowing alert suppression. Don’t publish 9093 to untrusted networks without confirming authentication is actually enforced.

How do I check if my Kafka broker on 9093 requires authentication?

Try an unauthenticated metadata listing: kcat -b <target>:9093 -L. If it returns brokers and topics, the listener is accepting anonymous connections and needs SASL/mTLS plus ACLs (allow.everyone.if.no.acl.found=false). Use openssl s_client -connect <target>:9093 to check the TLS certificate and whether the server requests a client certificate — no client-cert request on a listener meant to enforce mutual TLS is a misconfiguration.

How do I secure or close port 9093?

If it’s Kafka: enable SASL_SSL or mutual TLS on the listener, set allow.everyone.if.no.acl.found=false, and apply per-topic ACLs. If it’s Alertmanager: put it behind an authenticating reverse proxy and patch to 0.25.1+. Then firewall 9093 to only the clients, brokers, and monitoring hosts that need it, audit for an accidental 0.0.0.0:9093 in cloud/container configs, and rescan with nmap -p 9093 <target> to confirm the exposure is gone.

TL;DR

• Service: secured Apache Kafka broker listener (TLS/SSL or SASL_SSL, alongside plaintext 9092) — and, as a common collision, Prometheus Alertmanager’s API/UI
• Default port: 9093/TCP
• Biggest risk: an exposed Kafka broker with no authentication or ACLs = read/write every topic (data exfiltration, message injection) plus metadata disclosure; or a PLAINTEXT/mis-enforced “secure” listener; or, if it’s Alertmanager, an unauthenticated API leaking config/secrets and allowing alert-silence tampering
• Mitigation: identify the service first, then enforce SASL/mTLS + ACLs on Kafka (or auth-proxy Alertmanager), fix TLS, patch (CVE-2022-34917, CVE-2021-38153, and Kafka Connect CVE-2023-25194), and firewall 9093 to the hosts that need it