CVE-2026-114358 · Radius Xenia M2M Platform password recovery SQL injection

01 · The Real Story

A bank vault with the password-reset access panel left on an unguarded wall

The Radius Xenia M2M Platform takes user-supplied input from the password recovery page and drops it into SQL queries without proper parameterization. An unauthenticated attacker can send crafted SQL through the password reset fields to force the backend database to return rows, leak error details, enumerate schema, or accept stacked statements that modify records. The CVE record does not specify affected version ranges, so defenders should treat every currently deployed Xenia build as vulnerable until a vendor advisory says otherwise.

No vendor CVSS score is attached to this CVE. That lack of a baseline does not soften the impact: a network-reachable unauthenticated SQL injection in the management plane of a fleet/M2M platform is textbook critical. If the admin UI is internet-exposed, exploitation is nearly turn-key with sqlmap once the parameter is discovered. Even on a private APN or VPN, any compromised host on that segment becomes a full database attacker.

"Unauthenticated SQL injection in the Xenia password recovery form means the M2M database is one malicious reset request away."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the Xenia web management console

The attacker needs network connectivity to the Xenia web management interface, typically on 443 or 8443. If the console is exposed on the public internet this is a plain web request. If it sits on a private APN or VPN, the attacker must already be inside that network or have compromised a connected host.

Conditions required:

Network access to the Xenia web management TCP port
No mandatory IP allow-list or VPN enforcement

Where this breaks in practice:

Many M2M admin panels are placed on private RF/APN/VPN segments rather than the public internet
Perimeter firewalls commonly block inbound access to management interfaces

Detection/coverage: Shodan/Censys queries for Radius Xenia banners; next-gen firewall logs for inbound connection attempts to the management port.

STEP 02

Locate the password recovery form and identify the injectable parameter

The vulnerable function is in password recovery. The exact path and parameter name are not in the public record, but standard forgot-password endpoints are easy to fingerprint. Inputs such as username or email are concatenated into SQL statements.

Conditions required:

Password recovery is enabled in the interface
No CAPTCHA or aggressive rate-limiting that blocks parameter testing

Where this breaks in practice:

Repeated password-reset attempts may trigger account lockout or rate-limit alarms
Some deployments disable self-service recovery for administrator accounts

Detection/coverage: Web server access logs showing repeated forgot-password or recovery requests; WAF alerts for SQL metacharacters or unusual POST payloads.

STEP 03

Confirm injection and enumerate the database

The attacker sends boolean, error-based, or time-based payloads such as ' OR 1=1--, WAITFOR DELAY, or SLEEP(5), or simply runs sqlmap with the discovered endpoint and parameter. Error-based output reveals DBMS type, table names, and column structures without authentication.

Conditions required:

Backend database errors are returned or timing differences are observable
The web application does not filter all SQL metacharacters

Where this breaks in practice:

Application-level error masking may suppress DB error details
Input filters may block some SQL metacharacters, but CWE-89 means bypasses exist

Detection/coverage: WAF alert for SQLi; database audit logs may show unusual query patterns from the web application service account.

STEP 04

Extract sensitive data or modify records

Union-based or stacked queries allow the attacker to read account tables, telematics device credentials, hashed passwords, location history, and customer data. With the same injection, records can be altered to disable alerts, change ownership IDs, or escalate privileges.

Conditions required:

Database account used by the web app has SELECT and, for modification, INSERT/UPDATE/DELETE rights
Relevant data is stored in the same database

Where this breaks in practice:

A least-privilege DB account would slow modification, but the CVE record explicitly notes ability to modify database records
Network segmentation may limit what the DB service can reach, but not the data in its own tables

Detection/coverage: Database activity monitoring for anomalous SELECT/UPDATE volume; SIEM correlation of web-to-DB errors and large result sets.

STEP 05

Achieve fleet or tenant-wide impact

Once the attacker can modify database records, they may reset administrative credentials, inject commands into M2M dispatch or device command queues, or exfiltrate fleet-wide customer and vehicle data. In telematics contexts this can mean tracking vehicles, disabling devices, or sending fraudulent messages to endpoints.

Conditions required:

Targeted platform stores device credentials or command queues in the same database
Attacker obtains a foothold allowing database pivot

Where this breaks in practice:

Separation of web/database from the M2M command path reduces chance of immediate device control
Some platforms use signed commands or out-of-band checks for device actions

Detection/coverage: SOC alerting on mass data egress from the database; anomalous API calls to device command endpoints.

03 · Compensating Control

CRITICAL 9.8→HIGH 8.8

SEVERITY REDUCED

Restrict access to the Xenia web management interface to an administrative VPN or jumpbox — Deploy within 3 days. Remove inbound internet exposure immediately. This breaks the attack path at step 1 for most external attackers and reduces the reachable population to internal/LAN actors.

CRITICAL 9.8→IGNORE 0.0

SEVERITY REDUCED

Disable password recovery until a patched version is available — Deploy within 3 days. This removes the vulnerable input entirely and breaks the SQL injection path regardless of network location.

CRITICAL 9.8→HIGH 8.0

SEVERITY REDUCED

Deploy a WAF rule or reverse proxy filter for SQLi signatures on the password recovery endpoint — Deploy within 3 days as a compensating control. It blocks common sqlmap probes and error-based injection but is bypassable, so do not rely on it alone.

CRITICAL 9.8→IGNORE 0.0

SEVERITY REDUCED

Apply vendor patch as soon as issued — Check the vendor advisory and patch within 90 days per noisgate remediation SLA for CRITICAL. This eliminates the SQL injection.

What doesn't work

Changing the database account to read-only does not fully contain the vulnerability because the CVE states sensitive data can be read and schema enumerated; confidentiality remains lost.
Requiring MFA on administrator accounts does not stop the attack because the password recovery function is unauthenticated and occurs before authentication.
Enabling application error masking alone is insufficient; attackers can still use time-based blind SQLi or UNION queries that do not require error output.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known active exploitation; record is not on CISA KEV.
Public PoC availability	No named PoC on pocindex.io or GitHub at assessment; `sqlmap` can likely exploit the described SQLi once the endpoint and parameter are known.
EPSS score & percentile	0.00502 (0.5% predicted 30-day probability; low percentile band).
KEV status	Not listed in CISA KEV as of 2026-10-29.
CVSS vector & interpretation	No vendor vector supplied; our assessed vector is `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` = 9.8.
Affected version ranges	Not specified in the CVE record; treat all current Radius Xenia builds as vulnerable until a vendor advisory is published.
Fixed versions	None identified; vendor advisory is pending.
Scanning / exposure data	No public GreyNoise/Shodan/Censys data is cited in the record; defenders should scan their own external and internal asset inventory for Xenia web management interfaces.
Disclosure date	2026-10-29.
Reporting researcher/org	Not named in the record; likely vendor or coordinated disclosure.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

Assessed baseline: no vendor CVSS exists, so set baseline from CVSS 3.1 unauthenticated remote SQLi: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8.
Friction audit: endpoint reachability is the only meaningful gate. Private APN deployments reduce public exposure, but this CVE is about a web management plane that is often reachable by fleet managers over WAN and occasionally exposed directly.
Role multiplier: Xenia is a multi-tenant M2M/telematics platform; worst plausible high-value role includes fleet-wide data exfiltration and tampering with device records or command queues. That outcome floors the verdict at CRITICAL for canonical deployments.
Exploitability: no public PoC is required; once the vulnerable parameter is discovered, sqlmap weaponizes this within minutes.

Why not higher?

Already at the top of the practical scoring range. Only lack of confirmed public internet exposure and absence of an observed active exploit keep it from the theoretical 10.0. CVSS cannot exceed 10.0.

Why not lower?

Unauthenticated, remote, SQL injection with both read and write capability is unlike authenticated or local flaws. Even with no public PoC, exploitation is elementary and weaponizable with sqlmap; the data and device control value of an M2M platform makes it severe.

06 · Verification

Crowdsourced verification payload.

Run from any workstation that can reach the Xenia web management interface and has curl. Invoke as bash check_cve-2026-114358.sh https://xenia-admin.example.com. No special privileges required; the script sends non-destructive time-based probes and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# CVE-2026-114358 non-destructive SQLi probe for Radius Xenia password recovery
# Usage: $0 <base-url>
set -u
BASE="$1"
if [[ -z "$BASE" ]]; then echo "Usage: $0 <base-url>"; exit 2; fi
BASE="${BASE%/}"
ENDPOINTS=("passwordrecovery" "forgotpassword" "recover" "reset_password" "recoverpassword" "auth/forgot")
PARAMS=("email" "username" "user" "login")
PAYLOADS=("' OR 1=1-- -" "' OR SLEEP(5)-- -" "' OR pg_sleep(5)-- -" "' WAITFOR DELAY '0:0:5'-- -")
MAXTIME=8
FOUND=0
REACHABLE=0
for ep in "${ENDPOINTS[@]}"; do
  url="$BASE/$ep"
  code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$url" 2>/dev/null)
  [[ "$code" == "000" || "$code" == "404" || "$code" == "403" ]] && continue
  REACHABLE=1
  for p in "${PARAMS[@]}"; do
    for payload in "${PAYLOADS[@]}"; do
      resp=$(curl -s --max-time $MAXTIME -w '\nTIME:%{time_total} CODE:%{http_code}' -d "${p}=${payload}" -X POST "$url" 2>/dev/null)
      total=$(echo "$resp" | grep -o 'TIME:[0-9.]*' | cut -d: -f2)
      if [[ -n "$total" ]]; then
        if awk -v t="$total" 'BEGIN{ if (t >= 5.0) exit 0; exit 1 }'; then
          FOUND=1
        fi
      fi
      if [[ "$FOUND" -eq 1 ]]; then
        echo "VULNERABLE: time-based SQLi confirmed on $url with parameter $p using payload: $payload"
        exit 0
      fi
    done
  done
done
if [[ "$REACHABLE" -eq 0 ]]; then
  echo "UNKNOWN: no reachable password recovery endpoint found on $BASE"
  exit 3
else
  echo "PATCHED: reachable endpoints but no time-based SQLi detected with common payloads. Manual testing recommended."
  exit 0
fi