An unauthenticated SQL injection vulnerability exists in Sangoma Switchvox SMB Edition 8.3

CVE-2026-9586 is an unauthenticated SQL injection in Sangoma Switchvox SMB Edition 8.3 (build 104997). The /pa endpoint — designed to accept XML provisioning messages from IP phones — concatenates the user-controlled PhoneIP field directly into an unparameterized PostgreSQL query. An attacker sends a single crafted HTTP POST, gains arbitrary SQL execution against the backend database, and chains PostgreSQL's COPY TO PROGRAM (or equivalent) to achieve full remote code execution as the database service user on the underlying Linux host. No credentials, no user interaction, no complex race conditions. Affected versions are all Switchvox builds prior to 8.4.0.2; the fix shipped July 14, 2026.

The vendor's CRITICAL / 9.8 rating is exactly right — arguably even conservative given the current threat landscape. This is a textbook unauth-RCE with zero friction: network-reachable endpoint, trivial exploitation, and full host compromise. The CVSS 4.0 score of 9.3 aligns. With ~4,000 instances visible on Shodan, active automated scanning from at least one threat actor since August 30, a public PoC from Horizon3.ai, and CISA adding it to KEV on September 2, this is a live-fire emergency — not a theoretical risk.

Why this verdict

• Zero authentication barrier: The /pa endpoint requires no credentials, tokens, or session state. Any host that can reach the HTTPS port can fire the exploit — this is the most favorable attacker position possible (AV:N/PR:N/UI:N).
• Active KEV listing with confirmed campaigns: CISA added this to KEV on September 2, 2026, based on observed exploitation. Automated scanning has been hitting exposed instances since August 30. This is not theoretical.
• Public, weaponized PoC: Horizon3.ai's disclosure provides sufficient detail that sqlmap and custom scripts work out of the box. The barrier to entry for even low-skill attackers is effectively zero.
• Role multiplier: Switchvox is a network-edge VoIP appliance. In typical SMB deployments, it sits at the network perimeter or on a voice VLAN with routes to internal infrastructure. (a) *Low-value role:* lab/test PBX — blast radius is host-only. (b) *Typical role:* production PBX for a single site — blast radius is host + voice data + pivot to internal network. (c) *High-value role:* primary telephony gateway bridging external PSTN and internal network, often storing LDAP bind credentials, SIP auth secrets, call recordings (potentially regulated under HIPAA/PCI if recording payment or health calls), and SMTP relay configs. Compromise at this role = internal network pivot + sensitive data exfiltration. This is a network edge appliance in the high-value-role catalog. The chain succeeds identically across all roles. ≥80% of Switchvox installs serve as production PBX (typical or high-value role). The verdict floor is CRITICAL.
• No friction compounds against exploitation: Unlike vulns requiring local access, auth, or unusual configs, every default Switchvox install with an internet-reachable web port is exploitable. The only mitigant is network-level blocking, which ~4,000 orgs have evidently not applied.

Why not higher?

The CVSS 3.1 score is already 9.8, which is effectively the ceiling. The Scope is Unchanged (the vuln compromises the Switchvox host, not a separate security domain directly), which is the only reason it isn't 10.0. There is no reasonable higher bucket.

Why not lower?

Every downgrade factor is absent: the vuln requires no authentication, no user interaction, no local access, no unusual configuration. It is actively exploited in the wild, KEV-listed, has public PoC, and targets a network-edge appliance where compromise yields internal network pivot. Downgrading would be indefensible.

1. Block all external access to Switchvox web interface immediately — Place Switchvox behind a firewall rule or VPN that restricts HTTPS (port 443) access to the management and /pa endpoint from untrusted networks. This is the single most effective compensating control — if the endpoint isn't reachable, the exploit can't fire. Deploy within hours given KEV active exploitation status.
2. Apply Switchvox 8.4.0.2 update — This is the definitive fix. Sangoma released 8.4.0.2 on July 14, 2026. Under the noisgate mitigation SLA for CRITICAL with active exploitation, patch/mitigate immediately — within hours, not days. Schedule the update during the next maintenance window, ideally tonight.
3. Block egress from the Switchvox appliance — Configure outbound firewall rules so the Switchvox host can only reach required SIP trunking providers, NTP, and update servers. Block all other egress. This prevents a compromised host from establishing reverse shell callbacks. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
4. Hunt for indicators of compromise — Check for unexpected outbound connections from Switchvox (especially to 176.65.148.184), new cron jobs, unfamiliar processes spawned by PostgreSQL, and recently written files in /tmp or /var/tmp. Review PostgreSQL logs for anomalous queries against the provisioning tables. Do this today.
5. Rotate all credentials stored on Switchvox — After patching, rotate SIP trunk credentials, LDAP bind passwords, SMTP relay credentials, and any admin passwords stored on or accessible from the Switchvox appliance. Assume these were exfiltrated if the host was internet-exposed prior to patching.

Run this script on the Switchvox appliance itself (SSH as root) or from an auditor workstation that can reach the Switchvox HTTPS port. Usage: bash check_cve_2026_9586.sh <switchvox_host>. No special privileges needed when run remotely; root needed for local version check.

#!/usr/bin/env bash
# check_cve_2026_9586.sh — Detect CVE-2026-9586 vulnerable Switchvox
# Usage: bash check_cve_2026_9586.sh <hostname_or_ip>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

HOST="${1:-}"

if [ -z "$HOST" ]; then
  echo "Usage: $0 <switchvox_host_or_ip>"
  exit 2
fi

# Method 1: If running locally on the appliance, check installed version
if [ "$HOST" = "localhost" ] || [ "$HOST" = "127.0.0.1" ]; then
  if command -v switchvox_version &>/dev/null; then
    VER=$(switchvox_version 2>/dev/null || true)
  elif [ -f /etc/switchvox/version ]; then
    VER=$(cat /etc/switchvox/version)
  else
    VER=""
  fi
  if [ -n "$VER" ]; then
    echo "Detected Switchvox version: $VER"
    # Compare against fixed version 8.4.0.2
    if echo "$VER" | grep -qE '^8\.[0-3]\.' || echo "$VER" | grep -qE '^8\.4\.0\.[01]$'; then
      echo "VULNERABLE — version $VER is below 8.4.0.2"
      exit 1
    else
      echo "PATCHED — version $VER is 8.4.0.2 or later"
      exit 0
    fi
  fi
fi

# Method 2: Remote check — probe /pa endpoint for existence
echo "Probing $HOST for /pa endpoint..."
HTTP_CODE=$(curl -sk -o /dev/null -w '%{http_code}' \
  -X POST "https://${HOST}/pa" \
  -H 'Content-Type: text/xml' \
  -d '<?xml version="1.0"?><PhoneConfig><PhoneIP>127.0.0.1</PhoneIP></PhoneConfig>' \
  --connect-timeout 10 --max-time 15 2>/dev/null || echo "000")

if [ "$HTTP_CODE" = "000" ]; then
  echo "UNKNOWN — could not connect to $HOST on HTTPS"
  exit 2
elif [ "$HTTP_CODE" = "200" ] || [ "$HTTP_CODE" = "500" ]; then
  echo "VULNERABLE — /pa endpoint is reachable (HTTP $HTTP_CODE). Verify Switchvox version is below 8.4.0.2."
  echo "NOTE: This confirms endpoint exposure. Confirm version via admin UI or SSH."
  exit 1
elif [ "$HTTP_CODE" = "404" ] || [ "$HTTP_CODE" = "403" ]; then
  echo "PATCHED or mitigated — /pa endpoint returned HTTP $HTTP_CODE (blocked or removed)"
  exit 0
else
  echo "UNKNOWN — /pa endpoint returned HTTP $HTTP_CODE. Manual investigation required."
  exit 2
fi

Sources

1. Horizon3.ai Disclosure
2. Help Net Security — Active Exploitation Report
3. CISA KEV Catalog Addition
4. The Hacker News — Reverse Shell Deployment
5. SC World — Exploitation Brief
6. CVE Feed Detail
7. Vulnerability-Lookup (CIRCL)