Attackers Exploit Issabel Framework Flaw Enabling Unauthenticated OS Command Execution

Critical Issabel PBX Flaw Under Active Attack

A critical vulnerability in Issabel Framework, the web-based administrative layer for the open-source unified communications PBX platform, is being actively exploited to gain unauthenticated remote code execution on telephony servers. The flaw, tracked as CVE-2026-89026, carries a CVSS v3.1 score of 9.8 and a CVSS v4.0 score of 9.3 — putting it at the top end of the severity scale.

The Shadowserver Foundation first observed exploitation attempts in the wild on September 9, 2026, more than a month after a fix had already shipped, underscoring how many Issabel deployments remain unpatched and internet-facing.

What Is Issabel Framework?

Issabel is a widely deployed, free and open-source unified communications platform built on Asterisk, offering PBX telephony, call center, and messaging functionality out of the box. Organizations — from small businesses to larger enterprises — use it as a low-cost alternative to commercial PBX systems, often self-hosting it on internet-facing infrastructure so remote staff and branch offices can reach the phone system.

The Framework component is Issabel's web management layer: it exposes the pbxapi interface administrators use to configure extensions, trunks, and call routing, and it authenticates API requests using JSON Web Tokens (JWTs).

How the Vulnerability Works

The root cause is a classic hardcoded-secret bug (CWE-321): the Framework shipped with a hardcoded HS256 JWT signing key embedded directly in pbxapi/index.php, identical across every vulnerable installation. Because the signing key never varied between deployments, anyone with a copy of the source code effectively held the master key to every unpatched Issabel server on the internet.

With that key in hand, an attacker can:

1. Forge a valid bearer token — no login, password, or session of any kind is required.
2. Call the pbxapi/manager/originate endpoint using the forged token, which the server accepts as legitimate.
3. Abuse the System application parameter in that call, which instructs Asterisk to execute an arbitrary shell command on the underlying host, running as the Asterisk system user.

In short: a publicly known constant plus a documented API call is enough to turn an exposed Issabel PBX into a remote shell.

Evidence of Active Exploitation

According to researchers, the vulnerability was patched on August 1, 2026, when the hardcoded key was replaced with a per-installation secret stored in /etc/issabel.conf. Despite that fix being available, Shadowserver detected real-world exploitation attempts beginning September 9, 2026 — a gap that gave attackers over five weeks to identify and target servers that had not yet applied the update.

Public reporting has not disclosed attacker attribution, the volume of exploitation attempts, or specific victim organizations. Given the access level involved, security researchers warn that successful exploitation could let intruders eavesdrop on calls, harvest credentials stored on the PBX host, and pivot from the compromised server into the broader internal network — a common outcome when telephony infrastructure sits inside the corporate perimeter with broad network trust.

Affected Versions and Patch Status

• Affected: Issabel Framework builds prior to the fix commit b97dbaf0b71c1c36f841e672b664afbeb02773bd.
• Fixed: Versions containing that commit, which replace the shared hardcoded JWT secret with a unique key generated per installation and stored in /etc/issabel.conf.

Administrators should confirm not just that they have pulled a newer release, but that the specific fix commit is present in their running deployment — and that any previously issued tokens signed with the old shared key are no longer trusted.

Remediation Guidance for Issabel Administrators

1. Update immediately to a Framework build containing commit b97dbaf0b71c1c36f841e672b664afbeb02773bd or later.
2. Verify the JWT key was regenerated — check that /etc/issabel.conf holds a unique, non-default signing secret rather than the legacy hardcoded value.
3. Take the PBX API off the public internet. Restrict access to pbxapi and Asterisk management interfaces behind a VPN, firewall allowlist, or network segmentation — these interfaces were never meant to face the open web.
4. Audit logs for compromise indicators, including unexpected originate calls, bearer tokens issued outside normal admin sessions, and unfamiliar shell commands executed by the Asterisk process.
5. Rotate credentials stored on or accessible from the PBX host, since a compromised server should be treated as a potential foothold into the wider network.

Organizations running self-hosted Issabel PBX systems should treat this as an emergency patch — the combination of a hardcoded secret, an unauthenticated attack path, and confirmed in-the-wild exploitation makes this one of the more severe telephony-infrastructure flaws disclosed this year.

Related Reading

• CVE-2026-73570: Zimbra ZCS OS Command Injection via SMTP
• Soliton FileZen OS Command Injection Under Active
• Ivanti Connect Secure Under Active Attack - CISA Issues