CVE-2026-89026 · Issabel Framework Hard-Coded HS256 JWT Signing Key Enables…

01 · The Real Story

Every Issabel PBX on the planet was shipped with the same front-door key, and the burglars already have copies

The Issabel Framework — the web layer underpinning the popular open-source Issabel PBX unified-communications platform built on Asterisk — embedded a static HS256 JWT signing secret (da893kasdfam43k29akdkfaFFlsdfhj23rasdf) in its pbxapi/index.php file. Because the key is identical across every installation worldwide, any attacker who reads the source can forge a valid bearer token, hit the /pbxapi/manager/originate REST endpoint, and pass an arbitrary command string via the Asterisk System application. Asterisk dutifully executes it under the asterisk service account — giving the attacker unauthenticated remote code execution. All versions prior to commit b97dbaf are affected; the fix replaces the static key with an installation-specific secret stored in /etc/issabel.conf.

The vendor's CVSS 9.8 CRITICAL rating is essentially correct and, if anything, conservative in operational context. The chain requires zero authentication, zero user interaction, and zero special conditions — the key is public, the endpoint is reachable over HTTPS, and public proof-of-concept scripts automate the entire flow. Shadowserver confirmed active in-the-wild exploitation starting 2026-09-09, with attackers deploying cryptominers, web shells, reverse shells, and conducting VoIP toll fraud. VulnCheck independently scored it 9.3 on CVSS v4. We dock a half-point from 9.8 only because the initial shell lands as the asterisk user (not root), though local privilege escalation on these CentOS-based appliances is routinely trivial. The verdict stays CRITICAL.

"Skeleton key ships in every Issabel PBX — unauthenticated RCE is actively exploited in the wild."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain the hard-coded JWT secret

The attacker reads the publicly disclosed hard-coded HS256 signing key da893kasdfam43k29akdkfaFFlsdfhj23rasdf from the Issabel Framework source code, any of the published advisories, or the PoC repositories on GitHub. No scanning or interaction with the target is required for this step.

Conditions required:

Internet access to read public source code or advisories

Where this breaks in practice:

None — the key has been public since at least September 2026

STEP 02

Forge a valid JWT bearer token

Using the known HS256 secret, the attacker constructs a JWT with a valid payload structure (typically including an admin-level extension claim). Standard libraries like PyJWT or jsonwebtoken produce a valid token in a single function call. The PoC by AranFarzami (CVE-2026-89026.py) and cflowsec automate this step entirely.

Conditions required:

Knowledge of the JWT payload schema (documented in PoC)
Any JWT library (PyJWT, node jsonwebtoken, etc.)

Where this breaks in practice:

None — automated in multiple public PoCs

Detection/coverage: WAF rules inspecting Authorization: Bearer headers against known JWT payload patterns; however, the token is structurally valid, so generic JWT validation won't flag it.

STEP 03

Call the originate API endpoint

The attacker sends an authenticated POST to https://<target>/pbxapi/manager/originate with the forged bearer token in the Authorization header. The request body specifies the Asterisk System application and includes the OS command string as the data parameter. No additional authentication factors or CSRF tokens are required.

Conditions required:

Network reachability to the Issabel PBX web interface (typically TCP 443 or 8443)

Where this breaks in practice:

PBX admin interfaces behind a VPN or IP allowlist are not directly reachable
Enterprises using a reverse proxy with client-cert auth would block this

Detection/coverage: IDS/IPS signatures matching POST to /pbxapi/manager/originate with System in the body; Nuclei template available for proactive scanning.

STEP 04

Asterisk executes the command

The Asterisk Manager Interface (AMI) originate action processes the request and invokes the System() dial-plan application with the attacker-supplied command string. The command runs as the asterisk service account on the underlying Linux host. Typical payloads include reverse shells (bash -i >& /dev/tcp/...), wget/curl to pull second-stage malware, or direct cryptominer deployment.

Conditions required:

Asterisk service running (default on any functional Issabel install)

Where this breaks in practice:

If Asterisk is crashed or misconfigured, the call fails — extremely rare on production PBXs

Detection/coverage: Host-based: auditd / osquery rules on asterisk user spawning bash, sh, curl, wget, or any child process outside normal dial-plan execution.

STEP 05

Post-exploitation: privilege escalation and lateral movement

The asterisk user typically has write access to Asterisk configs, CDR databases (MySQL), voicemail spools, and SIP credentials. On default Issabel installations (CentOS-based), local privilege escalation via sudo misconfigurations, kernel exploits, or writable cron directories is common. Observed campaigns pivot from the PBX into the internal network, enumerate Active Directory, and exfiltrate call-detail records.

Conditions required:

Default Issabel OS installation with limited hardening

Where this breaks in practice:

Hardened Linux hosts with proper sudo policies and up-to-date kernels resist priv-esc
Network segmentation isolating the PBX VLAN limits lateral movement

Detection/coverage: EDR on the PBX host (uncommon); network-level: east-west traffic anomalies from the PBX subnet to internal hosts.

03 · Compensating Control

CRITICAL 9.3→LOW 2.5

SEVERITY REDUCED

Block external access to /pbxapi endpoints immediately — Deploy a firewall rule or reverse-proxy ACL that drops all inbound traffic to /pbxapi/* from non-trusted source IPs. This breaks step 3 of the attack chain (the originate call) without touching the application. Per the noisgate mitigation SLA for CRITICAL findings, deploy within 3 days — but given active exploitation, do this today. If remote PBX administration is required, restrict to VPN-only access.

CRITICAL 9.3→IGNORE 0.0

SEVERITY REDUCED

Apply commit b97dbaf to replace the hard-coded JWT key — Pull the patched Issabel Framework containing commit b97dbaf0b71c1c36f841e672b664afbeb02773bd, which replaces the static JWT secret with an installation-specific key generated on first run and stored in /etc/issabel.conf. This is the definitive fix. Deploy within the noisgate remediation SLA of 90 days for CRITICAL, but push for immediate deployment given active exploitation.

CRITICAL 9.3→HIGH 7.0

SEVERITY REDUCED

Rotate all SIP credentials and Asterisk Manager passwords — If the PBX was exposed while unpatched, assume the asterisk user had access to SIP secrets, AMI credentials, and CDR databases. Rotate all SIP trunk passwords, extension passwords, AMI user credentials, and MySQL passwords. Review /var/log/asterisk/full and Apache access logs for suspicious /pbxapi/manager/originate calls. Do this as part of the incident-response sweep within 3 days.

CRITICAL 9.3→MEDIUM 5.5

SEVERITY REDUCED

Network-segment the PBX into an isolated VLAN — Place the Issabel PBX on a dedicated VLAN with strict east-west firewall rules: allow only SIP/RTP traffic to the SBC/PSTN gateway, HTTPS from the management jump host, and NTP/DNS. Block all other outbound and lateral traffic. This limits post-exploitation lateral movement (step 5) even if the PBX is compromised. Deploy within 30 days.

What doesn't work

Generic WAF in front of the PBX — the forged JWT is structurally valid HS256, so signature-based WAF rules that check JWT format will pass it. You need endpoint-path blocking (/pbxapi/manager/originate), not token inspection.
Changing the Asterisk AMI password alone — the vulnerability bypasses AMI auth entirely; the JWT forging grants API-level access that calls AMI internally. The AMI password is never checked in this chain.
Rate-limiting the API — a single request is sufficient for full RCE. Rate-limiting does not stop a one-shot exploit.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	Active. Shadowserver Foundation observed exploitation starting 2026-09-09. Campaigns include cryptomining, VoIP toll fraud, web shell deployment, and network reconnaissance. Not yet on CISA KEV.
Proof-of-Concept Availability	Multiple public PoCs. AranFarzami/CVE-2026-89026 (Python scanner + exploit), cflowsec/CVE-2026-89026 (RCE PoC). Both automate JWT forging and `/pbxapi/manager/originate` exploitation. Nuclei template in development per ProjectDiscovery tracker.
EPSS	0.00685 (0.685%) — 30-day exploitation probability. Modest percentile, but lagging the reality of confirmed active exploitation.
CISA KEV Status	Not listed as of 2026-10-09. Given confirmed exploitation, KEV inclusion is likely imminent.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` = 9.8. Network-reachable, no auth, no interaction, full CIA impact. VulnCheck independently scored 9.3 on CVSS v4.
Affected Versions	All Issabel Framework installations shipping `pbxapi/index.php` before commit `b97dbaf0b71c1c36f841e672b664afbeb02773bd` (patched 2026-08-01). No formal version-number release exists — Issabel uses rolling commits.
Fixed Version	Commit b97dbaf. Replaces hard-coded key with installation-specific secret in `/etc/issabel.conf`. No downstream distro backports known.
Internet Exposure	Issabel PBX admin panels are commonly exposed on TCP 443/8443. No precise Shodan/Censys census published, but Shadowserver's active-exploitation feed confirms internet-wide scanning and exploitation against exposed instances. FreePBX (a comparable platform) shows ~10,700 exposed panels on Shodan — Issabel's footprint is smaller but non-trivial.
Disclosure Timeline	Hard-coded key present since pbxapi introduction → Patch committed 2026-08-01 → CVE published 2026-09-15 → Active exploitation observed 2026-09-09 (exploitation preceded formal CVE publication).
Reporting Credit	VulnCheck advisory; Shadowserver Foundation exploitation telemetry. Original researcher not publicly credited in advisories.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.3/10)

Why this verdict

Zero-friction exploit chain: The hard-coded key is publicly known, the endpoint requires no authentication, and multiple public PoCs automate the full chain from token forging to OS command execution. There is no step in this chain that requires skill, tooling, or access beyond network reachability.
Active exploitation confirmed: Shadowserver documented in-the-wild exploitation starting 2026-09-09 — six days *before* the CVE was even published. Campaigns are automated and opportunistic, targeting any internet-exposed Issabel instance. This alone anchors the verdict at CRITICAL.
Asterisk user, not root — minor friction: Initial code execution lands as the asterisk service account, not root. This is the sole reason for the 0.5-point score reduction from 9.8 to 9.3. However, local priv-esc on default CentOS-based Issabel appliances is routinely achievable, so this friction is thin.
Role multiplier: Issabel PBX occupies the *telephony infrastructure* role. (a) In low-value roles (lab/test), compromise is inconsequential. (b) In the typical SMB deployment — which represents the majority of the installed base — compromise yields call-detail records, SIP credentials, voicemail, toll-fraud capability, and a network pivot point. The blast radius is host → network segment, with financial impact via toll fraud. (c) In high-value roles — enterprises where the PBX carries sensitive voice traffic (legal, healthcare, finance) or is connected to SIP trunks with significant billing authority — the blast radius extends to data breach (CDR/voicemail), financial loss (toll fraud), and lateral movement into internal networks. PBX is not in the canonical high-value-role catalog (not a DC, hypervisor, or CI/CD system), so the CRITICAL floor from the catalog does not mechanically apply — but the *active exploitation* override keeps the verdict at CRITICAL regardless.
Niche product, limited enterprise footprint: Issabel is an open-source PBX used primarily by SMBs and telecoms in Latin America and emerging markets. It is not a tier-1 enterprise UC platform. This limits the population at risk compared to, say, a Cisco or Microsoft Teams vuln, but does NOT reduce severity for organizations that actually run it.

Why not higher?

A 9.8 or 10.0 would require either root-level initial access (the asterisk user is a service account, not root) or scope-change impact (S:C in CVSS terms). The chain lands as a non-root user on a single host. While priv-esc is likely, it is not guaranteed, and the blast radius does not inherently chain to domain-wide compromise without additional steps. The 9.3 reflects the near-worst-case reality while acknowledging this single friction point.

Why not lower?

Downgrading below CRITICAL would be indefensible. The chain is unauthenticated, remotely exploitable, requires no user interaction, and is under active exploitation with public PoCs. The hard-coded key means every unpatched instance on the internet is immediately compromisable — there is no per-instance secret to brute-force. Shadowserver telemetry confirms this is not theoretical. Even accounting for the asterisk user limitation and Issabel's niche footprint, the exploit's trivial weaponization and confirmed campaigns keep this firmly CRITICAL.

06 · Verification

Crowdsourced verification payload.

Run this script on each Issabel PBX host as root or any user with read access to /var/www/html/pbxapi/index.php. No arguments needed. Example: sudo bash check_cve_2026_89026.sh. Exits 1 if VULNERABLE, 0 if PATCHED, 2 if UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_89026.sh — Detect CVE-2026-89026 (Issabel Framework hard-coded JWT key)
# Run on the Issabel PBX host as root or a user with read access to the pbxapi source.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

PBXAPI_INDEX="/var/www/html/pbxapi/index.php"
KNOWN_KEY="da893kasdfam43k29akdkfaFFlsdfhj23rasdf"
CONF_FILE="/etc/issabel.conf"

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

# Check 1: Look for the known hard-coded key in the source file
if grep -qF "$KNOWN_KEY" "$PBXAPI_INDEX" 2>/dev/null; then
  echo "VULNERABLE — Hard-coded JWT signing key found in $PBXAPI_INDEX (CVE-2026-89026)."
  echo "  The static key '$KNOWN_KEY' is present. Patch immediately."
  exit 1
fi

# Check 2: Verify the patched version reads from issabel.conf
if grep -q 'issabel\.conf' "$PBXAPI_INDEX" 2>/dev/null; then
  if [ -f "$CONF_FILE" ]; then
    echo "PATCHED — $PBXAPI_INDEX references $CONF_FILE for JWT key (commit b97dbaf applied)."
    exit 0
  else
    echo "UNKNOWN — Source references $CONF_FILE but the file does not exist. Patch may be incomplete."
    exit 2
  fi
fi

# Check 3: Neither pattern matched — could be a custom fork or different version
if grep -qi 'HS256\|jwt\|JWT' "$PBXAPI_INDEX" 2>/dev/null; then
  echo "UNKNOWN — JWT references found in $PBXAPI_INDEX but neither the known hard-coded key nor the patched config-file pattern was detected. Manual review required."
  exit 2
else
  echo "UNKNOWN — $PBXAPI_INDEX exists but no JWT signing logic detected. This may be a different version of the framework."
  exit 2
fi