Port 10002 – documentum (EMC/OpenText Documentum Content Server Repository Port)

Port 10002 is registered with IANA as documentum — the native (cleartext) connection port for an EMC / OpenText Documentum Content Server repository, with 10003 (documentum_s) as its secure/SSL sibling. Documentum is a heavyweight enterprise content-management (ECM) platform, so the thing listening on 10002 is a content server “docbase”: the process that DFC (Documentum Foundation Classes) clients talk to over Documentum’s own RPC protocol to run DQL queries, fetch and store content, and drive workflow. One important nuance up front: 10002 is not the connection broker. Clients first ask a docbroker (connection broker) — default TCP 1489, secure 1490 — “where does docbase X live?”, and the docbroker replies with a host and port. By Documentum’s own port convention the first repository on a host uses 10000/10001, the next uses 10002/10003, and so on, which is exactly why the content-server pair landed on this number. So an open 10002 means a Documentum repository is directly reachable, and the real attack surface is the authenticated RPC/DQL interface behind it — plus the unauthenticated docbroker on 1489 that happily names your docbases for you.

Why It’s Open

Port 10002 is open because a Documentum Content Server repository is running and listening for client connections. In a normal deployment the flow is:

• A docbroker (connection broker) runs on 1489/1490 and acts as a directory service. It is queried without authentication and returns the list of docbases plus the host and native/secure port for each content server.
• Each Content Server repository (docbase) listens on its own native + secure port pair. The first repository conventionally uses 10000/10001, the second 10002/10003 — the pair IANA reserved as documentum (10002) and documentum_s (10003).
• DFC clients — Documentum Administrator (DA), Webtop, D2, xCP applications, idql/iapi, and third-party tools like dqMan — connect to that repository port to run RPC calls and DQL (Documentum Query Language) against the docbase.

So the port is open on purpose: it is how every Documentum client reaches the repository. The problem is that repositories hold contracts, filings, engineering drawings, HR records and other high-value content, and the connection is often exposed to a wider network than it should be — or the docbroker on 1489 is exposed alongside it, advertising every docbase name and server to anyone who asks.

Common Risks

• Unauthenticated docbroker enumeration. The connection broker on 1489 answers getdocbrokermap/getservermap queries with no credentials, disclosing docbase names, server hostnames, versions and the exact repository ports (like 10002) — a free map of the environment for an attacker.
• Weak or default repository credentials. The install owner account dmadmin is a repository superuser; shared, weak or reused dmadmin/service-account passwords turn a reachable 10002 into full docbase compromise. Self-service or LDAP-backed accounts can hand an attacker the low-privilege session that the escalation bugs below need.
• Authenticated privilege escalation to superuser. Multiple documented Content Server design flaws let any authenticated docbase user escalate to superuser via crafted RPC calls, TAR-batch symlinks, or dmr_content object manipulation (see CVEs).
• DQL injection. Applications that build DQL from user input — or Content Server’s own DQL-hint handling on an Oracle backend — allow injection that reads or alters content the user shouldn’t see.
• Bulk content exfiltration. A superuser or over-broad account can dump entire repositories — every document, version and rendition — along with the metadata that describes the organisation.
• Cleartext exposure on 10002 vs 10003. The native port (10002) is unencrypted; sniffable sessions and credentials are a real risk when clients don’t use the secure documentum_s port (10003).
• Workflow and audit tampering. Superuser access lets an attacker rewrite approvals, delete versions, and edit or purge audit trails, undermining the compliance that ECM systems exist to provide.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Work from the outside in: fingerprint the port, ask the docbroker what’s there, then (with valid credentials) exercise the DQL/RPC surface. Note there is no reliable “port 10002” Nmap NSE or Metasploit module — Documentum enumeration uses the platform’s own DFC tooling, so don’t expect a canned exploit path.

Detect the service and version

nmap -sV -p 1489,1490,10002,10003 <target>

Scanning the docbroker ports (1489/1490) alongside the repository ports (10002/10003) tells you whether you’re looking at a full Documentum stack or just an orphaned content-server port.

Grab the raw banner

nc -nv <target> 10002

The native Documentum RPC protocol is binary, so expect a non-ASCII handshake rather than a friendly banner — its presence still confirms a content server rather than some other high-port app.

Enumerate the connection broker (no auth)

# List docbrokers and the docbases/servers they know about — no credentials required
dmqdocbroker -t <target> -p 1489 -c getdocbrokermap
dmqdocbroker -t <target> -p 1489 -c getservermap <docbase>

dmqdocbroker is Documentum’s own diagnostic utility (shipped with the DFC runtime). getservermap returns the docbase’s server name, version, and the native/secure ports — often revealing the very 10002 you’re testing.

Query the repository with DQL (valid credentials)

# Interactive DQL client
idql <docbase> -U<user> -P<password>
# then, at the prompt:
#   select r_object_id, object_name, r_object_type from dm_sysobject enable(return_top 10);
#   select user_name, user_privileges from dm_user where user_privileges >= 16;

# Interactive API client (RPC-level: fetch, dump, get server config)
iapi <docbase> -U<user> -P<password>

idql (DQL) and iapi (server API/RPC) are the native Documentum command-line clients; user_privileges >= 16 flags superuser/sysadmin accounts, and third-party admin tools like dqMan or the web-based Documentum Administrator expose the same surface with a GUI.

Record every open 1489/10002/10003, each docbase name the docbroker leaked, the server version, and any account you validated, and push those findings straight into the pentest report so the evidence chain is intact rather than scattered across shell history.

What to Look For

Known CVEs and Exploits

Documentum Content Server has a genuine CVE history, and it clusters around one theme: an authenticated docbase user escalating to superuser, or reading data they shouldn’t, through the RPC/DQL surface that lives on this port. That makes weak repository credentials (or self-registration) the on-ramp, and these bugs the escalation. The most significant were disclosed by researcher Andrey B. Panfilov in 2017 and captured in CERT/CC VU#315340. All CVSS 3.x figures below are HIGH (8.8) because a low-privilege user reaches full superuser.

• CVE-2017-15012 — Content Server through 7.3 does not validate the input of the PUT_FILE RPC-command, letting any authenticated user hijack an arbitrary file from the content-server filesystem; because some of those files are security-sensitive, it leads to privilege escalation. CVSS 3.0 8.8. Public PoC: Exploit-DB 43003.
• CVE-2017-15276 — Content Server through 7.3 fails to verify the contents of TAR archives used for batch content upload, so symlinks inside the archive trigger a path-traversal that an authenticated user rides to superuser. CVSS 3.0 8.8. Public PoC: Exploit-DB 43002.
• CVE-2017-15013 — Content Server through 7.3 lets an authenticated user delete a dmr_content object and recreate one with the old identifier, replacing security-sensitive objects (e.g. a dm_method) to gain superuser privileges. CVSS 3.0 8.8.
• CVE-2014-2506 — Content Server before 6.7 SP1 P28 / SP2 P14 / 7.0 P15 / 7.1 P05 allows remote authenticated users to obtain super-user privileges for system-object creation and bypass data-access and server-action restrictions (EMC advisory ESA-2014-046). CVSS 2.0 8.5 (HIGH).
• CVE-2014-2520 — Content Server before 6.7 SP2 P16 / 7.1 P07, on an Oracle backend, improperly restricts DQL hints, allowing authenticated users to conduct DQL injection and read sensitive database content. CVSS 2.0 6.3.

Correction — wrong-service CVEs removed. The previous version of this page listed four CVEs that have nothing to do with Documentum and were removed after verification against NVD: CVE-2019-3989 is an Amazon Blink XT2 IoT-camera OS-command-injection bug; CVE-2020-5346 is a stored-XSS flaw in RSA Authentication Manager; CVE-2017-4971 is an Expression-Language injection in Pivotal Spring Web Flow; and CVE-2021-21563 is a denial-of-service issue in Dell EMC PowerScale OneFS storage. None affect Documentum Content Server or port 10002. Always confirm the vendor, product and description on the CVE’s NVD record before trusting a “Documentum” label.

Mitigation

• Don’t expose the docbroker or repository to untrusted networks. Firewall 1489/1490 and 10002/10003 to the application/DFC tier that legitimately needs them; the unauthenticated docbroker in particular should never be internet-reachable.
• Prefer the secure port. Use 10003 (documentum_s) / SSL-enabled connections instead of cleartext 10002, and configure clients to require it so RPC and credentials aren’t sniffable.
• Patch to a supported release. Content Server ≤ 7.3 is in range for the PUT_FILE, TAR-symlink and dmr_content escalation bugs — move to a current, patched OpenText Documentum build and apply the ESA-series fixes.
• Harden accounts. Give dmadmin/install-owner and service accounts strong, unique passwords; minimise the number of superusers; disable or tightly control self-registration; and integrate with enterprise auth (LDAP/SSO) with MFA where possible.
• Least privilege in the docbase. Restrict who can create system objects, call sensitive RPCs, or upload TAR batches; audit dm_user.user_privileges for accounts holding sysadmin/superuser they don’t need.
• Guard DQL. Parameterise or validate any application input that reaches DQL, and review DQL-hint handling on Oracle-backed repositories.
• Monitor and audit. Log docbroker queries and repository sessions, alert on superuser grants and audit-trail edits, and rescan to confirm 1489/10002/10003 are closed to the outside after locking down.

Real-World Example

The clearest illustration is the 2017 OpenText/EMC Documentum Content Server disclosure by Andrey B. Panfilov, catalogued as CERT/CC Vulnerability Note VU#315340. It bundled a family of design flaws in Content Server (through 7.3) that all shared the same devastating shape: a user who only holds an ordinary, authenticated docbase account could escalate to superuser. One variant abused the PUT_FILE RPC to hijack a security-sensitive file off the content-server filesystem (CVE-2017-15012); another smuggled a symlink inside a TAR upload batch so the extraction wrote outside its intended directory (CVE-2017-15276); a third deleted and recreated a dmr_content object to swap out a dm_method and run code as superuser (CVE-2017-15013). Working exploits were published to Exploit-DB. The lesson for port 10002 is direct: the repository’s real trust boundary isn’t “authenticated vs not” — a single low-privilege account, obtained through weak dmadmin-style credentials or self-registration, was enough to own an entire enterprise document store, which is why keeping the port off untrusted networks and patched to a current release matters so much.

FAQ

What is port 10002 used for?

Port 10002 is the IANA-registered documentum service — the native connection port of an EMC/OpenText Documentum Content Server repository (docbase). DFC clients (Documentum Administrator, Webtop, D2, idql/iapi, dqMan) connect here to run RPC calls and DQL queries against the content-management repository. Its secure/SSL sibling is 10003 (documentum_s).

Is port 10002 the Documentum docbroker?

No — that’s a common mix-up. The docbroker (connection broker) runs on TCP 1489 (secure 1490) and is only a directory service: clients ask it where a docbase lives, and it returns a host and port. That port is often 10002 because Documentum assigns repository pairs incrementally (10000/10001 for the first docbase, 10002/10003 for the next). The actual content-server RPC/DQL traffic goes to 10002, not to the docbroker.

Why is port 10002 open on my server?

Because a Documentum Content Server repository is running and listening for client connections. It’s expected on a Documentum content-management host. The concern is scope: if 10002 (or the docbroker on 1489) is reachable from networks beyond the trusted application tier, the repository — and the sensitive documents it holds — is more exposed than it should be.

What are the biggest risks on port 10002?

Unauthenticated docbroker enumeration (docbase names, servers and ports leaked from 1489), weak dmadmin/service-account credentials, authenticated privilege-escalation to superuser through documented Content Server bugs (PUT_FILE, TAR symlinks, dmr_content manipulation), DQL injection, and cleartext exposure on the native port versus the secure 10003.

Does port 10002 have real CVEs?

Yes. Documentum Content Server has verified network-facing CVEs — including CVE-2017-15012, CVE-2017-15276, CVE-2017-15013 (all through 7.3, authenticated user to superuser) and older ones like CVE-2014-2506 (privilege escalation) and CVE-2014-2520 (DQL injection). Note that several CVEs previously listed for this port were mislabeled products (a Blink camera, RSA Authentication Manager, Spring Web Flow, PowerScale OneFS) and have been removed.

How do I secure port 10002?

Firewall 1489/1490 and 10002/10003 to the DFC/application tier only, use the secure documentum_s port (10003) instead of cleartext, patch Content Server off any ≤ 7.3 release, enforce strong unique passwords for dmadmin and service accounts, apply least privilege inside the docbase, sanitise DQL, and monitor docbroker queries and superuser grants.

TL;DR

• Service: EMC/OpenText Documentum Content Server repository — the native connection port (IANA documentum), paired with 10003 (documentum_s, secure). The docbroker that points clients here is a separate service on 1489/1490, not on 10002.
• Default port: 10002/TCP (native) and 10003/TCP (secure); docbroker on 1489/1490. Repositories are assigned incrementally (10000/10001 first docbase, 10002/10003 next).
• Biggest risk: unauthenticated docbroker enumeration on 1489 plus weak dmadmin credentials leading to authenticated privilege-escalation to superuser (PUT_FILE, TAR-symlink and dmr_content bugs in Content Server ≤ 7.3), DQL injection, and cleartext exposure on 10002.
• Mitigation: keep 1489/10002/10003 off untrusted networks, use the secure port, patch to a current Documentum build, harden and minimise superuser accounts, sanitise DQL, and monitor the docbroker and repository sessions.

Related high-numbered service ports worth checking alongside this one: port 10001 (scp-config / Ubiquiti discovery & serial gateways) and port 10010 (RXAPI remote-execution service). Capture whatever you confirm on 10002 in a structured pentest reporting tool so the docbase names, versions and validated accounts stay linked to their evidence.