Port 50000 – Db2 (IBM Db2 LUW Database / DRDA Connection Port)

Port 50000 is the default TCP port for IBM Db2 (Db2 for Linux, UNIX and Windows — “Db2 LUW”). It is the DRDA listener — Distributed Relational Database Architecture, the wire protocol Db2 clients and drivers use to open a connection, authenticate, and run SQL against an instance. When you install Db2 LUW, the first instance’s db2c_<instance> service is wired to 50000 by default, and every JDBC, ODBC, CLI, or db2 client talks DRDA to that port. It is not, however, an exclusive number: 50000 is a popular “high port” that SAP NetWeaver AS Java uses for its default HTTP interface (instance 00 → 5<NN>00 = 50000), and it gets grabbed by dev servers, some Bosch and vendor software, and homegrown apps too. So on an open 50000 the first job is to confirm what is answering — but far and away the most security-relevant occupant is a Db2 database instance, and that is what this page leads with.

Why It’s Open

Port 50000 is open because an IBM Db2 LUW instance is listening for remote database connections. Db2 is IBM’s flagship enterprise RDBMS, running mission-critical OLTP and warehousing workloads across banking, insurance, government, and large enterprises, frequently on the same hosts as mainframe-adjacent middleware and SAP landscapes. The instance’s TCP/IP listener (SVCENAME / DB2COMM=tcpip) binds 50000 out of the box; SSL/TLS-encrypted DRDA usually rides an adjacent port such as 50001, and a companion DAS (Database Administration Server) discovery service historically answers on UDP/TCP 523.

Because 50000 sits above the well-known range and isn’t tied to a single ubiquitous OS service, other software squats it too. SAP NetWeaver Application Server Java exposes its ICM HTTP port as 5<instance>00, so an SAP system with instance number 00 answers HTTP on 50000. Various development frameworks, appliance web UIs, and internal tools also default here. That means an open 50000 is usually a Db2 database, sometimes an SAP Java web tier, and occasionally a custom app — so fingerprint before you assume.

Common Risks

• Internet-exposed Db2 instance. A database engine reachable from untrusted networks is a high-value target: it should almost never face the public internet, yet Db2 servers regularly turn up on internet-wide scans with 50000 wide open.
• Weak or default credentials. Db2 authenticates against OS accounts by default, and installs ship with well-known instance users — db2admin on Windows, db2inst1 / db2as / db2fenc1 on Linux/UNIX — that are frequently left with weak or default passwords. Guess one and you have a database session.
• Pre-auth DRDA protocol bugs. The DRDA parser has a history of serious flaws reachable before authentication, including a critical remote-code-execution bug in the pre-auth handshake and several unauthenticated denial-of-service crashes (see CVEs below). Simply reaching 50000 can be enough.
• Information / version disclosure. Version scans and the DAS discovery service happily reveal the Db2 product edition, version/fix-pack level, instance and node names, and platform — a precise map of which exploits apply.
• Data exfiltration and lateral movement. An authenticated foothold exposes sensitive business data, and Db2’s stored-procedure and administrative surface can be leveraged toward file access and OS-level command execution on the database host.
• Wrong service behind the port. If 50000 is actually an SAP AS Java web tier or a custom app, it carries that stack’s vulnerabilities instead — test what is really there.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Confirm it’s Db2, capture the version and any exposed instance metadata, then test authentication — all of which belongs in your pentest report as you go.

Detect the service and version

nmap -sV -p 50000 <target>

Nmap’s version detection fingerprints the DRDA listener and reports it as ibm-db2 with a version string when it can. If the response looks like HTTP instead, you’re probably looking at SAP AS Java or a custom web app — pivot to web testing.

Query the DAS discovery service (no auth)

nmap -sSU -sV -p 523 --script db2-das-info <target>

The db2-das-info NSE script connects to the IBM Db2 Administration Server on port 523 and exports the server profile with no authentication required — an easy source of version and configuration detail.

Grab the raw response

nc -nv <target> 50000

DRDA is a binary protocol, so a raw netcat session shows little on its own, but it confirms the port is live and lets you send a crafted DRDA EXCSAT/ACCSEC handshake if you’re testing the parser.

Metasploit Db2 module set

msfconsole -q

use auxiliary/scanner/db2/db2_version
set RHOSTS <target>
run

use auxiliary/scanner/db2/db2_auth
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
run

use auxiliary/scanner/db2/discovery
set RHOSTS <target>
run

db2_version probes the instance for version info, db2_auth brute-forces credentials against DRDA, and the discovery module queries the Db2 discovery service on UDP 523. (There is also auxiliary/admin/db2/db2rcmd, but that targets the Windows db2rcmd.exe named-pipe surface over SMB, not port 50000.)

Connect with the Db2 CLI

db2 catalog tcpip node testnode remote <target> server 50000
db2 attach to testnode user db2inst1 using <password>
db2 connect to SAMPLE user db2inst1 using <password>
db2 list db directory

Try the known defaults first — db2admin/db2admin (Windows), db2inst1/ibmdb2, db2as/ibmdb2, db2fenc1/ibmdb2 — then your wordlist.

Log every open port 50000, the exact Db2 version/fix-pack, any instance names from the DAS profile, and every credential that works, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Db2 has a long CVE history, but for a network port page only the ones reachable over the DRDA listener on 50000 (or the 523 discovery service) really matter. Many headline Db2 buffer overflows — CVE-2020-4204, CVE-2017-1105, CVE-2018-1799 — are actually local privilege-escalation or file-overwrite bugs (AV:L) that a remote attacker on 50000 cannot reach; they’re worth patching but are not port-50000 exposure. The network-facing, verified issues are:

• CVE-2026-10109 — Db2 11.5.0–11.5.9 and 12.1.0–12.1.4 are vulnerable to remote code execution through improper pre-auth DRDA handshake handling. Unauthenticated and network-reachable, CVSS 9.8 (Critical) (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H). This is the most serious modern Db2 bug on this port — reaching 50000 is enough to attempt it. Patch to the fixed special builds immediately.
• CVE-2012-0710 — Db2 9.1/9.5/9.7/9.8: a crafted DRDA request lets an unauthenticated remote attacker crash the database daemon (denial of service). CVSS 5.0 (AV:N/Au:N/A:P). No credentials required.
• CVE-2012-2180 — Db2 9.7/9.8: the DRDA chaining functionality mishandles a crafted request, triggering a NULL-pointer dereference and daemon crash. Unauthenticated remote DoS, CVSS 4.3 (AV:N/Au:N).
• CVE-2016-0211 — Db2 9.7/9.8/10.1/10.5: a malformed DRDA message causes the server to terminate abnormally (DoS). Network-reachable but requires an authenticated session (AV:N/PR:L), CVSS 4.3.
• CVE-2021-20373 — Db2 9.7 through 11.5: the LOAD utility fails to enforce directory restrictions, allowing information disclosure. NIST scores it 7.5 as network / no-privilege (AV:N/PR:N); IBM’s own score is more conservative (higher attack complexity). Either way it’s a real Db2 disclosure bug — patch it.
• CVE-2022-22483 — Db2 9.7 through 11.5: improper privilege management around CREATE OR REPLACE lets an authenticated low-privileged user read information they shouldn’t. CVSS 6.5 (AV:N/PR:L).
• CVE-2001-0051 — the original Db2 default-credentials flaw: Db2 UDB 6.1 created an account with a default username and password, giving unauthenticated remote database access. CVSS 7.5, archived as Exploit-DB 20472. Ancient, but the default-account pattern (db2admin, db2inst1, db2fenc1) it exposed is still the number-one way real Db2 servers fall today, and Metasploit’s db2_auth module exists precisely to exercise it.

Corrections to the previous version of this page. It cited CVE-2019-4443, which is RESERVED / not published in NVD and cannot be verified — removed. It listed CVE-2020-4414 as a “privilege escalation”; that CVE is a local shared-memory misuse bug (AV:L), not reachable over port 50000 — removed from the network list. And it labelled CVE-2022-22483 as “SQL injection”, which is wrong — it is an authenticated privilege-management information-disclosure issue, corrected above. Always confirm a CVE’s product and CVSS vector on NVD before trusting a stub’s summary.

Mitigation

• Never expose 50000 to the internet. A database listener belongs on an internal, segmented network. Firewall TCP/50000 (and UDP/TCP 523) to the specific application servers that need it, and audit cloud security groups and container mappings for an accidental 0.0.0.0:50000.
• Patch to a fixed fix-pack. The pre-auth DRDA RCE (CVE-2026-10109) alone justifies staying current; apply IBM’s special builds and keep Db2 on a supported, patched fix-pack level.
• Kill default and weak credentials. Rotate the passwords on db2admin, db2inst1, db2as, and db2fenc1, enforce a strong policy, and remove or lock unused accounts. Prefer least-privilege database roles over broad SYSADM grants.
• Require TLS. Configure Db2 SSL so DRDA traffic is encrypted (typically on 50001) and disable or firewall the plaintext listener where possible, so credentials and query data aren’t sniffable.
• Disable the discovery service (DISCOVER=DISABLE) if you don’t need DAS discovery — it hands out version and configuration detail for free on 523.
• Confirm what’s really listening. If 50000 is an SAP AS Java tier or a custom app rather than Db2, harden that stack instead (patch, WAF/reverse proxy, authentication) and keep it off untrusted networks.
• Rescan after changes with nmap -p 50000 <target> to confirm the port is closed or restricted, and route the findings straight into your pentest reporting tool.

Real-World Example

The cleanest illustration of why an exposed 50000 matters is the DRDA parser itself. For years the pre-auth Db2 code path that handles the DRDA handshake and chaining has produced bugs an attacker can hit without any credentials at all: CVE-2012-0710 and CVE-2012-2180 let a single crafted DRDA packet crash the database daemon, and in 2026 the same pre-auth handshake surface produced CVE-2026-10109, a CVSS 9.8 remote-code-execution flaw affecting Db2 11.5 and 12.1 — meaning any Db2 instance on those releases with 50000 reachable could be taken over by an unauthenticated attacker who merely completes (or abuses) the handshake. Pair that with how often real Db2 servers still answer on 50000 with default instance accounts (db2admin/db2admin, db2inst1/ibmdb2) intact, and the pattern is the textbook enterprise-database exposure: a high-value engine, on a memorable port, reachable from somewhere it never should have been. The fix is unglamorous and effective — patch the fix-pack, kill the defaults, and get the port off any untrusted network.

FAQ

What is port 50000 used for?

Port 50000 is the default TCP port for IBM Db2 for Linux, UNIX and Windows (Db2 LUW) database instances. It carries the DRDA protocol that clients and JDBC/ODBC drivers use to connect, authenticate, and run SQL. The same high port is also used by SAP NetWeaver AS Java (HTTP for instance 00) and by assorted development and vendor apps, so an open 50000 should be fingerprinted — but most often it’s a Db2 database.

Is port 50000 always IBM Db2?

No. Db2 is the dominant and most security-relevant occupant, but 50000 is a common “high port” pick. It’s the default HTTP port for SAP NetWeaver AS Java instance 00, and various dev servers, appliances, and custom apps bind it too. Run nmap -sV -p 50000 <host>: an ibm-db2 fingerprint is Db2, an HTTP response points to SAP or a web app.

Is it dangerous to leave port 50000 open?

To the internet, yes. A Db2 instance is a database engine full of sensitive data, and its DRDA listener has had pre-auth vulnerabilities including a critical remote-code-execution bug (CVE-2026-10109) and several unauthenticated denial-of-service crashes. Combined with commonly-unchanged default accounts, an exposed 50000 is a serious risk. Keep it on an internal, firewalled, TLS-protected segment.

What are the default Db2 credentials to check?

Db2 authenticates against OS accounts, and installs create well-known instance users: db2admin on Windows and db2inst1, db2as, and db2fenc1 on Linux/UNIX, historically with the password ibmdb2. These defaults (the root of CVE-2001-0051) are still a leading cause of Db2 compromise — rotate them to strong, unique passwords.

How do I identify the Db2 version on port 50000?

Use nmap -sV -p 50000 <host> to fingerprint the DRDA listener, Metasploit’s auxiliary/scanner/db2/db2_version, or the unauthenticated db2-das-info NSE script against the discovery service on port 523 (nmap -sSU -p 523 --script db2-das-info <host>), which exports the server profile including version and node names.

How do I secure or close port 50000?

Firewall TCP/50000 (and 523) to only the application servers that need it, keep Db2 patched to a fixed fix-pack, enable TLS for DRDA, and change every default instance password. If nothing legitimately needs the port, disable the TCP/IP listener (DB2COMM) or stop the instance, then rescan with nmap -p 50000 <host> to confirm it’s closed.

TL;DR

• Service: IBM Db2 LUW database server (DRDA connection listener); also used by SAP NetWeaver AS Java and custom/dev apps — fingerprint to be sure
• Default port: 50000/TCP (TLS/DRDA usually 50001; DAS discovery on UDP/TCP 523)
• Biggest risk: an internet-exposed Db2 instance with default/weak credentials, plus pre-auth DRDA bugs — a critical unauthenticated RCE (CVE-2026-10109) and several unauthenticated DoS crashes
• Mitigation: keep 50000 off untrusted networks and firewall it, patch to a fixed fix-pack, enforce TLS, and rotate db2admin/db2inst1/db2as/db2fenc1 off their defaults
• Related database ports: MySQL on 3306, PostgreSQL on 5432, and MongoDB on 27017