Active Exploitation
🔥 CyberForge CVE of the Day #053
🚨 CVE-2026-89026 — Issabel PBX: a shared signing key becomes forged API authority
The signature checks out. The caller never belonged there.
Issabel Framework's shared HS256 signing key lets outsiders forge PBX API tokens and reach OS command execution as Asterisk. The documented chain needs no legitimate account or user interaction.
The CVSS v3.1 score is 9.8 Critical; the CNA also assigns CVSS v4.0 9.3 Critical.
VulnCheck attributes exploitation evidence from 9 September 2026 to Shadowserver. The July repair does not establish when packaged deployments received it.
⚠️ Contain exposed APIs, verify the repair and investigate historical access.
🎯 The quick hit.
Vulnerable: Issabel Framework's PBX API authentication before the cited repair.
Consequence: forged JWT authority can lead to command execution as Asterisk.
Who should care: operators of reachable Issabel PBXs, including standby and cloned systems.
First action: restrict API access, then deploy the supported code fix and strong configured signing material together.
🔑 Key details:
⭐ Severity: Critical
📊 CVSS v3.1: 9.8; CVSS v4.0: 9.3
🧮 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
🧠 Weakness: CWE-321 — Use of Hard-coded Cryptographic Key
🎯 Targets: Issabel Framework supporting Issabel PBX
🧩 Vulnerable boundary: attacker-created JWT → trusted PBX API operation
🌐 Attack vector: Network
⚙️ Attack complexity: Low
🔓 Privileges required: None; no legitimate credentials needed
👆 User interaction: None
🔀 Scope: Unchanged under CVSS v3.1
⚔️ Confirmed impact: authentication bypass leading to OS command execution
💥 CVSS impact: High confidentiality, integrity and availability impact
👤 Execution context: Asterisk service user
🛡️ Fix: supported Framework build containing commit b97dbaf, plus valid secret provisioning
🔑 Additional remediation: retire shared-key trust; investigate and rotate exposed credentials if compromise is suspected
🚨 Active exploitation: reported by the CNA, attributed to Shadowserver
🧪 Reproduction: no independently validated standalone public PoC in this review; none executed
📋 CISA KEV: absent from the 14 September catalogue retrieved during today's research
📉 EPSS: no score or percentile returned during the 16 September research check
🗓️ Earliest reported exploitation evidence: 9 September 2026
🩹 Vendor patch: commit b97dbaf0b71c1c36f841e672b664afbeb02773bd, 31 July 2026
📜 Vendor bulletin: patch verified; separate bulletin and first-fixed RPM mapping not verified
🏷️ Reporter: The Shadowserver Foundation, credited by the CNA
🔬 Campaign research: original Shadowserver telemetry not independently retrieved
🧬 What actually went wrong?
A JWT signature should distinguish trusted issuance from an outsider's invention. HS256 uses a symmetric secret: anyone possessing it can generate accepted signatures. Issabel embedded the same key across installations, so correctly functioning cryptography could still produce an invalid trust decision.
1️⃣ The credential is manufactured
The shared key lets an outsider create a bearer token accepted by the verifier.
2️⃣ The forged authority reaches a powerful operation
The CNA identifies manager originate functionality as the command-capable path reached with forged authority.
3️⃣ API trust becomes operating-system activity
The System application causes commands to execute under the Asterisk account.
No signing-key value, token-generation instructions, weaponised request or reproduction recipe is included here.
🔐 A token in the request does not mean a legitimate login.
This is not an alg:none bypass or a guessed password. The attacker manufactures the expected credential, explaining “Privileges Required: None” despite a token being present. Hunt for unexpected operations and their consequences — not merely requests lacking an Authorization header.
⚔️ The practical attack chain:
1️⃣ A network path reaches an affected Issabel PBX API.
2️⃣ The attacker creates a bearer token using knowledge of the embedded signing material.
3️⃣ The vulnerable verifier accepts the token without a genuine login.
4️⃣ The resulting API authority reaches manager originate functionality.
5️⃣ The System application path causes command execution as Asterisk.
6️⃣ Subsequent access is limited or expanded by the service account's real permissions, available secrets and network reach.
Steps 1–5 are the CNA's mechanism; step 6 is environmental analysis, not observed campaign behaviour.
👤 Execution context — what the attacker actually gets.
The documented account is Asterisk, not root. Additional privilege requires separate evidence.
Depending on the deployment, that account may be able to:
🔹 read telephony configuration or service credentials;
🔹 access recordings, voicemail or other permitted data;
🔹 modify writable PBX files;
🔹 launch child processes and contact internal services;
🔹 abuse call-related capabilities available to the compromised process.
These are permission-dependent investigation leads, not observed campaign outcomes. Review groups, helper permissions, writable paths and egress before assigning a blast radius.
Not established: root access, ransomware, confirmed recording theft, toll fraud, persistence or lateral movement in a named campaign.
📦 Affected products and versions.
🔴 Issabel Framework before the repair commit:
b97dbaf0b71c1c36f841e672b664afbeb02773bd
The official range is Git-based; no first-fixed RPM or appliance image was verified. “Issabel 4” or “Issabel 5” alone cannot establish safety. Verify the supported build's patch inclusion or equivalent backport — not alphabetical hash order or an Asterisk-only update.
Include standby nodes, DR images and old clones in inventory; copied images may also carry copied secrets.
Deployment detail that matters: the patched API reads pbxapijwtsecret from /etc/issabel.conf. It requires a nonempty value that passes strict Base64 decoding and produces at least 32 bytes. Missing or invalid configuration is rejected.
Deploy code and secret together: missing configuration can break API operation. Never restore the shared key to regain compatibility. Base64 is encoding, not encryption or proof of randomness.
🕰️ Timeline / exploitation window.
🟢 31 July 2026: upstream repair committed; the CNA also records this as the public date.
🔴 9 September 2026: first exploitation evidence attributed to Shadowserver in the CVE description.
🔴 15 September 2026: CVE published, followed by the NVD record.
🔍 16 September 2026: CyberForge research and publishing review.
Operational conclusion: hunt from 9 September or earlier, extending to historical exposure and retained telemetry. First observation is not first attack; exposure is not proof of compromise.
👁️ Defender hunting guide:
These are analyst hunt leads, not validated signatures. No verified campaign-specific IOC set was available.
1️⃣ Establish the exposure window
Record Framework provenance, API and direct-backend reachability, privileges, patch time and runtime validation time. Compare exposure against the reported exploitation window.
2️⃣ Correlate API activity with approved integrations
Review /pbxapi/ and manager originate activity for unfamiliar clients, odd hours or bursts. Correlate accepted operations with host telemetry: reusable tokens can explain missing logins, and HTTP success alone proves neither legitimacy nor command execution. Avoid logging full Authorization headers; bearer tokens are credentials.
3️⃣ Inspect the Asterisk process tree
Inspect unexpected Asterisk child shells, interpreters or network clients; retain parent, account, time and connection details. Compare with legitimate dialplan activity. Review writable PBX files, scheduled tasks and service-account startup changes; these are general hunt locations, not CVE-specific IOCs.
4️⃣ Connect host activity to network and call records
Correlate suspicious requests with outbound DNS, proxy and firewall events. Check call records and provider billing for unexplained destinations, hours or spend. Validate anomalies; the CVE does not itself establish toll fraud.
5️⃣ Check the secrets and integrations within reach
Assess access to manager-interface, trunk, API and database secrets. Check their use after patching as well as before it. Preserve off-host and provider records when local evidence is incomplete.
🩹 Emergency remediation order:
1️⃣ Contain API exposure and preserve evidence
Limit API access to approved clients. Preserve web, Asterisk, OS and call records without delaying urgent containment. Plan API restrictions separately from SIP/media traffic to protect calling continuity.
2️⃣ Deploy the supported Framework repair
Use an update or supported backport incorporating the cited commit. No universal update command or first-fixed RPM was verified; confirm package provenance with the vendor.
3️⃣ Provision and verify the signing secret
Provision strong random material meeting the decoded-length requirement. Protect configuration and backups; avoid secret reuse across unrelated installations. Define intentional cluster sharing and rotation explicitly. Length checks cannot prove entropy: relocating the old constant would preserve the flaw.
4️⃣ Verify active code, configuration and token trust
After any required reload, verify the repaired API and intended secret are active. Test integrations and calls, reissue legitimate tokens, and confirm retired-key tokens fail. Never print secrets into validation logs.
5️⃣ Rotate other credentials according to compromise scope
After containment, replace exposed or reasonably reachable secrets from a clean administrative environment. An administrator-password reset alone cannot repair this key-based bypass.
6️⃣ Restore host integrity when it cannot be established
Engage incident response and PBX support. Rebuild from trusted media when compromise is confirmed or unbounded, restore reviewed configuration and validate before reconnecting. A repaired verifier cannot remove existing persistence.
These recovery recommendations are CyberForge analysis, not a separately published Issabel incident-response playbook.
🧱 Temporary exposure reduction:
✅ Restrict PBX API routes to explicitly approved clients, including direct back-end routes.
✅ Disable an unused API through supported controls where operationally safe.
✅ Limit unnecessary outbound access while preserving required telephony services.
✅ Alert on unusual Asterisk child processes and API-to-process correlations.
Keep an administrative recovery path. These controls do not replace the fix; no CVE-specific managed WAF rule was verified.
🚑 When vulnerability management becomes incident response.
Escalate API activity correlated with unexpected processes, outbound traffic, altered PBX settings or credential misuse. Inadequate logs on an exposed system warrant deeper assessment — not a clean bill of health or an automatic compromise claim. Preserve evidence and assess connected services; installing the update is not incident closure.
📊 CISA KEV and EPSS context.
Checks on 16 September 2026 returned no FIRST score or percentile. CISA's official mirror returned a 14 September catalogue without this identifier. Neither observation overrides the CNA's exploitation report; no CISA deadline or zero-risk prediction is implied.
🧾 Evidence separation.
Vendor-confirmed through code: the upstream patch replaces embedded signing material with a configured secret and rejects missing, invalid or too-short decoded values.
CNA-reported / researcher-attributed: VulnCheck documents the chain and attributes 9 September exploitation evidence to Shadowserver. Original telemetry was not independently retrieved; CyberForge executed no exploit.
CyberForge interpretation: exposed deployments need emergency treatment. Repair, secret validation and compromise assessment solve different problems; downstream access depends on local privileges.
Not established: a first-fixed RPM matrix, a named actor, victim count, campaign payloads, automatic root access or a complete IOC set. Public patch availability does not prove fleet-wide deployment.
🔥 CyberForge verdict:
CVE-2026-89026 is an authentication trust failure that turns a shared secret into outsider-controlled API authority.
Restore signing trust and investigate prior access. A configuration field alone is not protection: strong material must be provisioned, protected and used by the running service.
The correct order is:
1️⃣ Contain API exposure and preserve useful evidence.
2️⃣ Deploy the Framework fix and provision the secret together.
3️⃣ Verify active code, authorised integrations and retired-token rejection.
4️⃣ Hunt historical access and rotate other exposed credentials as warranted.
5️⃣ Rebuild when host integrity cannot be established.
6️⃣ Monitor connected services and telephony records for follow-on abuse.
The one-sentence CyberForge verdict: a valid signature proves possession of a key — not permission to use your PBX.
🔗 Issabel Foundation repair:
https://github.com/IssabelFoundation/framework/commit/b97dbaf0b71c1c36f841e672b664afbeb02773bd
🔗 Official CVE record and exploitation attribution:
https://www.cve.org/CVERecord?id=CVE-2026-89026
🔗 NVD vulnerability record:
https://nvd.nist.gov/vuln/detail/CVE-2026-89026
🔗 CISA official KEV mirror:
https://github.com/cisagov/kev-data/blob/develop/known_exploited_vulnerabilities.json
🔗 FIRST EPSS:
https://api.first.org/data/v1/epss?cve=CVE-2026-89026
#CyberSecurity #CVE #Issabel #PBXSecurity #ThreatHunting #CyberForge
Post summary
The text reports active exploitation of CVE-2026-89026 (Issabel PBX) attributed to Shadowserver as of 9 September 2026, with a CVSS 9.8 Critical severity. It provides detailed technical vulnerability information and remediation steps including a vendor patch commit and configuration changes, but no public PoC or exploit code is shared.
