Port 10010 – rxapi (Open Object Rexx API Daemon)

Port 10010 is registered by IANA as rxapi, the API daemon of Open Object Rexx (ooRexx) — the open-source successor to IBM’s Object REXX. rxapi is not a remote-execution service in the “run my commands” sense; it is an inter-process communication (IPC) broker that holds the state shared between cooperating Rexx interpreters on a machine: the Rexx data queues, the macrospace, and the registrations for external functions, subcommand handlers, and exits. Since ooRexx 4.x it does this over a socket interface rather than the shared memory older versions used, and on Unix/Linux that socket lives on TCP 10010. The catch is that rxapi was designed as a local helper with no authentication — so an rxapi that ends up reachable over the network is local IPC accidentally exposed to strangers. And because 10010 is a high, forgettable port, plenty of unrelated things squat it too: appliance admin panels, alternate/webmin-style HTTP, Docker-adjacent tooling, and in-house apps. So the first job on an open 10010 is to fingerprint what actually answers before assuming it is rxapi.

Why It’s Open

The legitimate reason 10010 is open is that ooRexx is installed and the rxapi daemon is running. Any host that runs Rexx programs which use the data queue (RXQUEUE), the macrospace, or externally registered functions needs rxapi alive to hold that shared state; it starts as a background daemon (rxapi / rxapid.service) and opens its socket so the interpreters can talk to it. On Windows the equivalent IPC is more local in nature, but on Unix/Linux builds the socket is a TCP listener, and historically that listener has been bound broadly rather than pinned to loopback — which is exactly how a machine-local daemon ends up answering on a public interface.

Beyond ooRexx, an open 10010 frequently has nothing to do with Rexx at all. The port sits well above the well-known range, so it gets grabbed by device management interfaces, alternate HTTP/proxy front-ends, container and orchestration side-channels, and custom internal services. Its neighbours in the 1000x block are just as service-specific — port 10001 and port 10002 each carry their own registered daemons — so a number alone tells you nothing. An open 10010 on a random host is therefore ambiguous by default: it might be an ooRexx install, or it might be a completely different product that simply chose the number. Confirm which before you act on it.

Common Risks

• Unauthenticated IPC exposed to the network. rxapi has no login, token, or ACL — it trusts whoever connects. That is fine for a loopback-only helper and dangerous the moment the socket is reachable off-box. A remote client can speak to the queue/macrospace/registration server directly.
• Data-queue tampering and disclosure. The Rexx data queue is a shared message channel between programs. An attacker who can reach rxapi may be able to read, inject, or drain queued data, corrupting or eavesdropping on whatever local Rexx automation relies on it.
• Macrospace and registration abuse. rxapi tracks the macrospace and external function/subcommand/exit registrations. Manipulating that shared state can alter what a subsequently-run Rexx program loads and executes, which — depending on the build and how those scripts run — is a plausible path toward influencing code execution on the host. Treat it as a serious integrity risk, not a curiosity.
• Denial of service. A daemon never meant to face hostile input is an easy target for malformed-packet crashes or resource exhaustion, taking out the local Rexx automation that depends on it.
• Wrong-service assumptions. Because 10010 is squatted by unrelated apps, both attackers and defenders misidentify it. A management panel, alternate HTTP interface, or custom app on 10010 carries its own vulnerabilities — miss the fingerprint and you test the wrong thing entirely.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The entire task on port 10010 is identifying the service before testing it — rxapi versus a web/app service look nothing alike once you look.

Detect the service and version

nmap -sV -p 10010 <target>

Grab the raw banner

rxapi speaks a binary socket protocol, so expect a non-printable or empty response rather than a friendly banner. That in itself is a signal it is not a plain text service.

nc -nv <target> 10010

Rule HTTP in or out

Much of the real-world traffic on 10010 is an alternate/admin web interface. A clean HTTP response means it is almost certainly not rxapi — read the headers and test it as a web app instead.

curl -sik http://<target>:10010/
curl -sik https://<target>:10010/

A Server:, WWW-Authenticate:, or redirect header identifies a web/appliance front-end you then fingerprint and test on its own terms.

Confirm an ooRexx host

If the port looks like rxapi, corroborate it: an ooRexx installation ships the interpreter and the daemon together, so a Rexx runtime on the box (or an rxapi / rxapid process) is strong confirmation you are looking at the real thing.

# On a host you control / have access to
rexx -v
ps -ef | grep -i rxapi

Run a scripted vulnerability check

nmap --script vuln -p 10010 <target>

There is no rxapi-specific Nmap NSE script or Metasploit module — do not trust any tutorial that claims one exists. Capture every open port 10010, the service you positively identified, and any queue/macrospace behaviour you confirm, so the evidence lands in the pentest report instead of a scratch terminal you will lose.

What to Look For

Known CVEs and Exploits

There are no genuine CVEs for ooRexx’s rxapi daemon. A keyword search of the NVD for ooRexx, rxapi, and Object Rexx returns zero network-facing vulnerabilities for this service. The real, well-understood problem here is a design-level exposure, not a patchable bug: rxapi is an unauthenticated local IPC broker, and running it where the network can reach it — historically made easy by the daemon binding its socket broadly on Unix rather than to loopback — hands an attacker the Rexx queue, macrospace, and registration state with no credentials required. There is no exploit to patch; the fix is to not expose it.

The previous version of this page cited CVE-2001-0870 as an “RXAPI buffer overflow.” That CVE is nothing of the sort — it is a missing-authentication issue in Alchemy Eye / Alchemy Network Monitor (an unrelated Windows network-monitoring product) that exposes its eye.ini file over HTTP. It has no connection to ooRexx, rxapi, or port 10010, so it has been removed, along with the stub’s vague, unverified “IBM AIX/OS-2 RXAPI remote execution” claims. Verify every CVE against its NVD record and confirm the product before trusting it.

If the service on 10010 turns out to be a web panel, appliance, or custom app rather than rxapi, the CVEs that matter are that product’s — identify it precisely and check its own advisories.

Mitigation

• Bind rxapi to loopback, and firewall 10010. rxapi is a local helper; nothing off-box should ever reach it. Keep the daemon on 127.0.0.1 and block TCP 10010 at the host and network firewall so it is never internet- or LAN-wide reachable.
• Don’t run rxapi where you don’t run Rexx. If a host has no ooRexx workload, the daemon should not be running at all — stop and disable it and rescan to confirm 10010 is closed.
• Segment the hosts that must run it. Where ooRexx automation legitimately needs rxapi, isolate those systems and restrict the port to the trusted management/automation range only.
• Treat the daemon as untrusted-input-facing if it can’t be fully closed off. Run it as an unprivileged user, keep ooRexx patched to a current release, and monitor for unexpected connections to 10010.
• If it’s not rxapi, secure the real service. Fingerprint the actual product, put any admin/web interface behind authentication and TLS, and patch it — don’t harden “port 10010” generically.

Real-World Example

The canonical port-10010 problem is not a headline breach but a configuration trap that repeats across ooRexx deployments. rxapi is written as a machine-local IPC broker with zero authentication, on the reasonable assumption that only cooperating Rexx interpreters on the same box will ever talk to it. On Unix/Linux, however, it does that talking over a TCP socket, and when that socket is bound to all interfaces instead of loopback, the “same box only” assumption quietly evaporates. A host doing routine Rexx automation then answers on 10010 to the whole network, and anyone who connects is speaking directly to the process that holds the data queues, the macrospace, and the external-function registrations — able to read and inject queue data and manipulate the shared state that local Rexx programs depend on, all without a single credential. It is the textbook shape of an “internal-only” service exposed by a default bind, and the reason the honest first step on an open 10010 is to fingerprint what is really there and then get it off the public interface.

FAQ

What is port 10010 used for?

Port 10010 is IANA-registered to rxapi, the API daemon of Open Object Rexx (ooRexx). rxapi is a local inter-process broker that manages the Rexx data queues, the macrospace, and external function/subcommand/exit registrations shared between Rexx programs on a host, communicating over a socket (TCP 10010 on Unix). The same port is also commonly squatted by unrelated appliance panels, alternate HTTP interfaces, and custom apps.

Is rxapi a remote command-execution service?

No — despite the “API” name and old descriptions calling it “remote execution,” rxapi is an IPC daemon for cooperating local Rexx interpreters, not a remote shell. Its danger is different: it has no authentication, so if it is reachable off the host an attacker can manipulate the Rexx queue/macrospace state directly, which can in turn influence what local Rexx programs execute.

Does rxapi have any known CVEs?

No. The NVD lists no vulnerabilities for ooRexx, rxapi, or Object Rexx. The risk is a design-level exposure — an unauthenticated local daemon reachable over the network — rather than a patchable bug. An old version of this page wrongly attributed CVE-2001-0870 (an Alchemy Eye/Network Monitor issue) to rxapi; that has been corrected.

Why is port 10010 open on my server?

Most likely because ooRexx is installed and the rxapi daemon is running to support Rexx automation. If you don’t run Rexx, 10010 is probably a different product that grabbed the number — an admin/web panel, alternate HTTP service, or in-house app. Fingerprint it (nmap -sV, curl -sik http://host:10010/) before assuming which.

How do I tell rxapi apart from a web app on 10010?

Check whether it speaks HTTP. rxapi answers with a binary socket protocol and no readable banner; a web/appliance service returns HTTP headers to curl -sik http://<host>:10010/. Confirm rxapi by checking the host for an ooRexx runtime (rexx -v) or an rxapi/rxapid process.

How do I secure port 10010?

If it’s rxapi: bind it to loopback, firewall TCP 10010 so nothing off-box can reach it, and disable the daemon entirely on hosts that don’t run Rexx. If it’s another service, identify the product, put its admin surface behind authentication and TLS, and patch it. Rescan afterwards to confirm the port is closed to untrusted networks.

TL;DR

• Service: rxapi — the Open Object Rexx (ooRexx) API daemon that brokers Rexx data queues, the macrospace, and function/subcommand/exit registrations between local processes; 10010 is also widely squatted by unrelated appliance/web/custom services
• Default port: 10010/TCP
• Biggest risk: an unauthenticated local IPC daemon exposed to the network (often via a broad socket bind on Unix), letting anyone read/inject queue data and manipulate shared Rexx state — no CVEs, a design-level exposure
• Mitigation: bind rxapi to loopback and firewall 10010, disable it on non-Rexx hosts, segment the systems that need it, and if it’s a different service on 10010, fingerprint and harden that product instead