Port 1978 – UniSQL (UniSQL Database)

Port 1978 is the registered port for UniSQL, listed by IANA as the service name unisql on both TCP and UDP. UniSQL was an early-1990s object-relational database from UniSQL, Inc. (founded by database researcher Won Kim); the company was acquired and its products discontinued by the late 1990s, so the registration long outlived any product behind it. The “TeraTerm / Open Mic” labels sometimes attached to 1978 are informal and unverified — Tera Term is a Windows terminal-emulator client, not a service that listens on 1978, and IANA registers no such names. In practice the thing most likely answering on 1978 today is Kyoto Tycoon, a lightweight key-value database server that defaults to this port, or a custom app — and, historically, a worm backdoor. As with port 666 and port 1000, the real job when you find 1978 open is to identify what is actually listening.

Why It’s Open

Legacy IANA assignment. The unisql label lingers in port databases and scanner output, so tools still recognise 1978 by name even though UniSQL itself is effectively dead.
Kyoto Tycoon default. Kyoto Tycoon — the network server on top of the Kyoto Cabinet key-value store — uses 1978/TCP as its default HTTP port, so an open 1978 on a modern host is most plausibly this rather than UniSQL.
Custom apps on a plausible-looking port. 1978 is registered but effectively unused, which makes it an attractive place to park a hand-rolled service that looks legitimate to a cursory review.
Backdoor / worm squatting. The Apache/OpenSSL Slapper worm’s “Cinik” variant used UDP 1978 for its control channel (see below), and the same “looks official, isn’t” logic still makes it a candidate for backdoors.

Common Risks

Unknown, unauthenticated service. The biggest risk on 1978 is simply not knowing what it is. An open listener on a registered-but-obsolete port deserves immediate fingerprinting rather than a shrug.
Exposed Kyoto Tycoon. Kyoto Tycoon speaks plain HTTP with no authentication or transport security of its own — an internet-facing instance on 1978 is effectively an open key-value store: anyone who reaches it can read, write, or delete records, and the RPC interface can clear the whole database.
Backdoor / C2 default. UDP 1978 sits on classic worm-port references thanks to the Slapper/Cinik variant — the same “plausible number” pattern as NetBus on 12345 and Back Orifice on 31337. Legacy, but the motif recurs.
False attribution. A stray unisql label in scan output can lull you into ignoring a real backdoor or an exposed database. Never trust the label — verify the service.

Want to save time on reporting?

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

Enumeration & Testing

Detect and fingerprint the service

nmap -sV -p 1978 <target>

Nmap may print unisql from its service database — treat that as a guess from the port number, not a verified protocol. There is no dedicated UniSQL NSE script or Metasploit module; the entire task is identifying whatever actually answers.

Probe UDP as well

nmap -sU -sV -p 1978 <target>

The assignment covers both transports, and the historic worm backdoor was UDP-only — so check UDP too; a listener may answer on only one.

nc -nv <target> 1978

A raw connect proves the port is open and often reveals a banner, prompt, or HTTP response that gives away a custom app or database.

Test for Kyoto Tycoon over HTTP

curl -s http://<target>:1978/rpc/report

Kyoto Tycoon’s network protocol is HTTP; its RPC report procedure returns server stats. A useful answer here confirms an exposed, unauthenticated key-value store rather than UniSQL.

Log every open instance and whatever you fingerprint so it lands in the final pentest report instead of a scratch terminal.

What to Look For

Checkpoint	What it means
TCP or UDP 1978 open and answering	Something is bound to the port — identify it; it is almost never real UniSQL
Nmap reports `unisql`	A service-database guess from the port number, not a verified protocol — confirm with a banner grab
HTTP response or `Server` header on 1978/TCP	Likely Kyoto Tycoon or another web service — enumerate it as an exposed key-value store
Unauthenticated read/write to a key-value store	Exposed Kyoto Tycoon — full data read, write, and delete with no login
A listener or traffic on 1978/UDP	Recall the Slapper/Cinik worm backdoor — treat an unexplained UDP listener as suspicious
No banner, silently drops connections	Custom or undocumented service — fingerprint deeper or capture the traffic

Known CVEs and Exploits

No port-1978 network-service CVEs. There are essentially no CVEs for UniSQL, for unisql as a listening service, or for “port 1978” itself — UniSQL was never a widely deployed daemon, and NVD has no UniSQL database entry.
Tera Term CVEs are the client, not this port. Tera Term (the terminal emulator) does have real CVEs — buffer overflows and macro/parsing bugs fixed in recent releases — but those affect the Windows client application, not a network service on port 1978. Don’t miscredit Tera Term client bugs to this port.
Kyoto Tycoon: exposure, not a CVE. If 1978 is a Kyoto Tycoon instance, the problem isn’t a specific vulnerability — it’s that the server ships with no authentication, so simply reaching it means full database access. Treat an exposed instance as a misconfiguration finding.
The real exposure is the unknown service. Treat an open 1978 as “identify this listener,” then apply whatever CVE and exploit research matches the software you actually find — a database, a custom web app, or a backdoor — rather than a UniSQL-specific bug.

Mitigation

Identify what’s really on 1978 first. Fingerprint the service before anything else. If it isn’t something you deliberately configured, treat it as suspicious.
Lock down or firewall Kyoto Tycoon. If it’s a legitimate Kyoto Tycoon store, never expose it to untrusted networks — bind it to localhost or a private segment and put access control (a reverse proxy, firewall rules, or a VPN) in front, since the server has no built-in auth.
Close it if it isn’t sanctioned. There’s no reason to expose a vestigial port like 1978 on a modern host — block it at the firewall and stop the listener.
Don’t run unknown services on registered-but-obsolete ports. A plausible-looking assignment like unisql is exactly what a backdoor hides behind; put real services on documented ports and record them.
Hunt for backdoors, especially on UDP. An unexplained 1978 listener — particularly on UDP — is an incident-response trigger: check the process and its parent, autostart entries, and outbound connections.
Monitor and alert. Add 1978 to IDS and egress rules so any new listener or C2-style traffic is flagged early.

Real-World Example

Port 1978’s most concrete story is a worm. In September 2002 the Apache/OpenSSL Slapper worm spread across Linux web servers through a buffer overflow in OpenSSL; its original backdoor listened on UDP 2002 to build a peer-to-peer DDoS network. Within days a variant known as “Cinik” appeared using UDP 1978 instead — a registered-but-unused port that looks more legitimate to a quick review than a random high port. That is the whole lesson of 1978: the unisql label describes a database that has been dead since the late 1990s, so anything actually answering is far more likely to be a modern key-value server like Kyoto Tycoon, a custom app, or a leftover backdoor. The name is a distraction — every time, the fix is to fingerprint the service rather than trust the port.

FAQ

What is port 1978 used for?

Port 1978 is the IANA-registered port for unisql, the UniSQL object-relational database, on both TCP and UDP. UniSQL has been defunct since the late 1990s, so the registration is largely vestigial. In practice an open 1978 is more likely to be Kyoto Tycoon (which defaults to this port), a custom application, or a historic worm backdoor than genuine UniSQL traffic.

Is port 1978 TeraTerm or “Open Mic”?

No — those labels are informal and unverified, and IANA doesn’t register 1978 under either name. Tera Term is a Windows terminal-emulator client that connects out to services like SSH and Telnet; it doesn’t run a listening service on 1978. If you see those names in a port list, treat them as folklore and fingerprint whatever is actually bound to the port.

What service runs on port 1978?

Officially unisql. Realistically, the most common real service is Kyoto Tycoon, a lightweight HTTP-based key-value database server that uses 1978 as its default port. Beyond that it may be a custom app or, historically, the Slapper/Cinik worm backdoor on UDP. Always fingerprint the listener instead of trusting the port label.

Is port 1978 dangerous?

The port isn’t dangerous by itself — what’s dangerous is an unidentified or misconfigured service on it. An exposed Kyoto Tycoon store has no authentication, and an unexplained UDP listener echoes a known worm backdoor, so an open 1978 you didn’t deliberately configure should be verified before it’s trusted.

How do I secure or close port 1978?

Identify the service first. If it’s a legitimate Kyoto Tycoon instance, firewall it to trusted hosts or bind it to localhost and add access control, since it has no built-in auth. If the listener is unexplained, stop the process, block 1978 at the firewall, and investigate the host for compromise. Rescan to confirm 1978 no longer answers.

TL;DR

Service: unisql (IANA) — the long-defunct UniSQL object-relational database; the assignment is largely vestigial
Default port: 1978/TCP and 1978/UDP (also Kyoto Tycoon’s default HTTP port)
Biggest risk: an open 1978 is rarely real UniSQL — it’s more likely an unauthenticated Kyoto Tycoon store, a custom app, or a historic worm backdoor (Slapper/Cinik on UDP), so the finding is “identify the unknown service”
Mitigation: fingerprint what’s actually on 1978, lock down or firewall an exposed Kyoto Tycoon, close it if it isn’t sanctioned, and treat an unexplained listener as an IR trigger