The Issabel Framework

CVE-2026-89026 is a hard-coded HS256 JWT signing key embedded in the Issabel Framework's pbxapi/index.php file. Because the secret is identical across every installation, any attacker who reads the source can forge a valid bearer token, call the Asterisk Manager Interface's Originate action with the System application parameter, and execute arbitrary OS commands as the asterisk user. All versions of the Issabel Framework prior to commit b97dbaf are affected — there is no version-range nuance; if you haven't pulled that commit, you're vulnerable.

The vendor's CRITICAL / 9.8 rating is honest and, if anything, slightly generous to the vendor for acknowledging it clearly. The attack requires zero authentication, zero user interaction, and zero complexity — the key is literally in the public source tree. Shadowserver observed active exploitation six days before the CVE was even published (2026-09-09 vs. 2026-09-15), meaning adversaries were already scanning and popping boxes while defenders had no advisory to act on. This is a textbook worst-case for a hardcoded credential class vulnerability.

Why this verdict

• Zero-friction attack chain: The hardcoded key is in public source code, forging a JWT requires one CLI command, and the originate endpoint gives direct OS command execution. There are zero prerequisites beyond network reachability — no credentials, no user interaction, no race conditions.
• Active pre-disclosure exploitation: Shadowserver observed attacks starting 2026-09-09, six days before the CVE was published. This was a zero-day being actively weaponized, which overrides any theoretical friction analysis.
• Role multiplier: Issabel PBX is a unified communications appliance. In its typical deployment role, it sits on a telephony VLAN with connectivity to SIP trunks and internal extensions. A compromised PBX enables call interception, voicemail exfiltration, toll fraud, and lateral movement into internal network segments. While not a domain controller or hypervisor, PBX appliances function as network-adjacent infrastructure with sensitive data access (call recordings, contact directories). For organizations running Issabel, 100% of their Issabel instances occupy this role. The blast radius is host → telephony infrastructure → potential network pivot, which sustains CRITICAL.
• Universal vulnerability: Unlike configuration-dependent bugs, the hardcoded key means every single unpatched instance is vulnerable with identical exploit code — no target-specific adaptation needed.
• No compensating controls by default: Issabel ships without WAF, API rate limiting, or JWT key rotation. The default install is the vulnerable install.

Why not higher?

The score is already at 9.6/CRITICAL. A 10.0 would require wormable/self-propagating capability or automatic root-level access. The Asterisk user, while powerful on the appliance, is not root by default, and propagation requires attacker-driven scanning rather than self-replication.

Why not lower?

Downgrading below CRITICAL would require either significant friction in the attack chain (there is none — hardcoded key, public source, one API call) or a negligible blast radius. Active in-the-wild exploitation before disclosure eliminates any theoretical-only discount. Even though Issabel has a smaller install base than enterprise PBX platforms like Cisco CUCM, the combination of zero-skill exploitation and confirmed active attacks means every affected instance is in immediate danger.

1. Block external access to Issabel web UI and pbxapi immediately — Place the Issabel management interface and pbxapi endpoint behind a VPN or firewall rule that restricts access to management workstations only. This is the single most effective control and should be deployed within the noisgate CRITICAL mitigation SLA of 3 days. If the PBX must be internet-facing, use a reverse proxy that strips or rejects requests to /pbxapi/.
2. Rotate the JWT signing key manually — If you cannot immediately pull commit b97dbaf, manually replace the hardcoded key in pbxapi/index.php with a strong random secret (≥ 256-bit). This invalidates all forged tokens. Generate with openssl rand -hex 32. Deploy within 3 days per noisgate CRITICAL mitigation SLA.
3. Monitor for originate endpoint abuse — Add a WAF rule or web server log alert for POST requests to the manager originate endpoint, especially those containing Application=System in the body. Any hit is likely malicious. Deploy monitoring within 3 days.
4. Network-segment the PBX — Ensure the Issabel PBX is on an isolated VLAN with no routing to sensitive internal segments (AD, file servers, databases). This limits post-compromise lateral movement. Should already be in place; verify within 3 days.
5. Audit for compromise indicators — Check web server access logs for unusual POST requests to /pbxapi/ endpoints, unexpected processes running under the asterisk user, new SSH keys in /var/lib/asterisk/.ssh/, and anomalous outbound connections. Given exploitation since 2026-09-09, assume breach if the instance was internet-exposed and unpatched.

Run this script on the Issabel PBX host itself as any user with read access to the web directory (typically root). Invoke with: sudo bash check_cve_2026_89026.sh. No arguments required.

#!/bin/bash
# CVE-2026-89026 Checker — Issabel Framework Hardcoded JWT Key
# Run on the Issabel PBX host as root or a user with read access to the web root.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

PBXAPI_INDEX="/var/www/html/pbxapi/index.php"

if [ ! -f "$PBXAPI_INDEX" ]; then
  echo "UNKNOWN — $PBXAPI_INDEX not found. Is Issabel installed on this host?"
  exit 2
fi

# Check for hardcoded JWT key patterns.
# The vulnerable code contains a static string used as the HS256 secret.
# After the fix (commit b97dbaf), the key is loaded from a config file or environment.
if grep -qiE '(jwt_secret|signing_key|HS256)' "$PBXAPI_INDEX" 2>/dev/null; then
  # Look for hardcoded string assignment vs config-based loading
  if grep -qE "^[^/]*['\"][A-Za-z0-9+/=]{16,}['\"]" "$PBXAPI_INDEX" 2>/dev/null && \
     grep -qiE '(jwt|sign|secret|key)' "$PBXAPI_INDEX" 2>/dev/null; then
    # Check if the key is loaded from config/env (patched) or inline (vulnerable)
    if grep -qE '(getenv|parse_ini_file|include|require|config).*secret' "$PBXAPI_INDEX" 2>/dev/null; then
      echo "PATCHED — JWT secret appears to be loaded from configuration, not hardcoded."
      exit 0
    else
      echo "VULNERABLE — Hardcoded JWT signing key detected in $PBXAPI_INDEX."
      echo "Apply commit b97dbaf or later from IssabelFoundation/framework immediately."
      exit 1
    fi
  fi
fi

# Fallback: check the git commit if the repo is present
FRAMEWORK_DIR="/usr/share/issabel" # common install path
if [ -d "$FRAMEWORK_DIR/.git" ]; then
  if git -C "$FRAMEWORK_DIR" merge-base --is-ancestor b97dbaf HEAD 2>/dev/null; then
    echo "PATCHED — commit b97dbaf is in the current branch."
    exit 0
  else
    echo "VULNERABLE — commit b97dbaf is NOT in the current branch."
    exit 1
  fi
fi

echo "UNKNOWN — Could not definitively determine patch status. Manually inspect $PBXAPI_INDEX for a hardcoded JWT secret string."
exit 2

Sources

1. OffSeq Threat Radar — CVE-2026-89026 Advisory
2. THREATINT — CVE-2026-89026
3. IssabelFoundation/framework GitHub Repository
4. Shenlong CVE Platform — Issabel Hardcoded JWT Key Intel
5. Shadowserver Foundation — Scans and Exploitation Telemetry
6. Red Sentry — JWT Vulnerabilities List 2026
7. Vulners — Issabel PBX CVE History