One Shared JWT Secret Exposes Issabel PBX Servers to Remote Command Execution

A universal signing key breaks API authentication

Attackers are exploiting a critical vulnerability in Issabel Framework, the web framework behind the open-source Issabel PBX and unified communications platform.

Tracked as CVE-2026-89026, the flaw allows a remote, unauthenticated attacker to execute arbitrary operating-system commands as the Asterisk user. Exploitation does not require stolen credentials, prior access, or user interaction.

The vulnerability originates in pbxapi/index.php, where Issabel Framework stored an HS256 JSON Web Token signing key directly in the application code. The secret was identical across installations:

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Because HS256 uses the same secret to create and verify a JWT signature, anyone who knows that value can generate tokens accepted by vulnerable Issabel systems. Embedding the secret in distributed source code therefore removes the security boundary that the token is supposed to enforce.

The weakness is classified as CWE-321: Use of Hard-coded Cryptographic Key.

Which Issabel Framework installations are affected

The official affected range covers Issabel Framework versions from 0 up to, but not including, commit:

b97dbaf0b71c1c36f841e672b664afbeb02773bd

Some vulnerability descriptions use the abbreviated reference b97dbaf. Administrators should rely on the complete hash when verifying whether a deployment includes the fix.

No numbered release boundary has been disclosed. Organizations cannot safely determine exposure solely from a general Issabel PBX product name or a release family; they need to establish whether their installed Framework code incorporates the corrective commit.

The vulnerability has critical ratings under two CVSS standards:

CVSS version	Score	Severity	Vector
CVSS 4.0	9.3	Critical	CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
CVSS 3.1	9.8	Critical	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Both assessments reflect the same central problem: the vulnerable interface is network-accessible, attack complexity is low, and exploitation needs neither privileges nor interaction from a legitimate user.

Issabel PBX operators are the directly exposed group. The immediate execution context is the Asterisk account; no confirmed privilege-escalation stage or higher operating-system access has been described.

From forged token to operating-system command

The exploitation chain combines the shared secret with a powerful PBX API operation.

First, the attacker signs a JWT using the hard-coded HS256 key. The resulting token is then presented to the Issabel PBX API as a bearer credential. Since the vulnerable server verifies signatures with the same embedded secret, it treats the manufactured token as authentic.

The attacker then targets this endpoint:

/pbxapi/manager/originate

The manager originate function can invoke an Asterisk application. By specifying the System application and supplying a command, the attacker causes Asterisk to pass that command to the underlying operating system.

The sequence is therefore:

1. Create a JWT signed with the secret shared by vulnerable installations.
2. Submit that token to the PBX API.
3. Call /pbxapi/manager/originate.
4. Select the System application.
5. Supply an operating-system command for execution by the Asterisk process.

This is not limited to unauthorized call initiation or manipulation of telephony settings. The confirmed outcome is arbitrary command execution within the permissions available to the Asterisk user.

The flaw also demonstrates why rotating passwords or tightening interactive login controls does not address the root cause. The attacker is not authenticating through a normal user account. Instead, the server is accepting a cryptographically valid token created with a secret that was never unique or private.

Exploitation was observed before the CVE record appeared

A patch was reported as having been pushed on August 1, 2026. The Shadowserver Foundation subsequently observed evidence of exploitation on September 9, 2026.

The CVE Program record, published and updated on September 15, 2026, credits Shadowserver and marks the vulnerability with the x_known-exploited-vulnerability tag. It also identifies the project as open source through the x_open-source tag.

The identity of the attacker or attackers is not known. There is also no disclosed estimate of how many Issabel installations were scanned, targeted, or compromised.

Available information does not describe payloads, persistence techniques, follow-on activity, or the operational infrastructure behind the attacks. Consequently, defenders cannot yet associate the exploitation with a named campaign or use a published set of campaign-specific indicators.

The CVE Program’s known-exploited designation should not be confused with inclusion in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. No separate CISA KEV entry, addition date, remediation deadline, or ransomware-use flag has been reported for CVE-2026-89026.

The fix makes the JWT secret installation-specific

Administrators should update Issabel Framework to code that includes commit:

b97dbaf0b71c1c36f841e672b664afbeb02773bd

The remediation removes the shared secret from pbxapi/index.php. Instead, the Framework obtains the JWT signing key from:

/etc/issabel.conf

That change gives each installation its own configured signing secret rather than relying on a value distributed with the application. Tokens generated using the old universal key should consequently fail validation after the corrected code and configuration are in place.

No separate workaround has been disclosed. There is also no documented recommendation that network filtering alone can safely compensate for leaving the vulnerable implementation installed.

Where immediate patching is impossible, reducing access to the PBX API may lower exposure, but it should not be treated as a confirmed vendor workaround. The underlying authentication failure remains present until the Framework is updated and no longer accepts tokens signed with the embedded key.

What defenders can investigate

Because exploitation is confirmed, patching should be accompanied by an incident review rather than treated only as preventive maintenance.

The limited technical indicators currently available are:

/pbxapi/manager/originate

System

da893kasdfam43k29akdkfaFFlsdfhj23rasdf

Administrators can review web, API, reverse-proxy, and Asterisk-related logs for unexpected requests to the manager originate endpoint, particularly requests involving the System application. They should also look for operating-system commands launched by Asterisk that do not correspond to expected administrative activity.

The disclosed JWT key is useful for identifying vulnerable source code or configuration assumptions, but it is not a campaign-specific indicator. Its presence shows that an installation contains the unsafe design; it does not, by itself, prove compromise.

No validated detection rule, forensic indicator package, malicious IP list, or payload signature has been published. Post-exploitation behavior is also unknown. Organizations finding suspicious API activity should therefore examine the broader host for unauthorized processes, modified files, scheduled execution, and other changes made under the Asterisk account, while avoiding assumptions about a single attacker playbook.

The priority is clear: verify the installed Framework revision, deploy the corrected JWT-key handling, and investigate exposed systems for prior use of the vulnerable API path.