Attackers Exploit Critical Issabel PBX Flaw to Execute OS Commands Without Authentication

A critical vulnerability affecting the Issabel Framework is being actively exploited, allowing remote attackers to execute operating-system commands on vulnerable PBX servers without providing valid credentials.

Tracked as CVE-2026-89026, the vulnerability stems from a hard-coded cryptographic key used to sign JSON Web Tokens (JWTs) in Issabel's PBX API.

The flaw carries a CVSS v3.1 score of 9.8 and a CVSS v4.0 score of 9.3, placing it firmly in the critical-severity category.

Security firm VulnCheck says vulnerable Issabel installations contain the same hard-coded HS256 JWT signing key. An attacker who knows that shared secret can create a forged bearer token that the server accepts as legitimate.

The forged token can then be used against a PBX management endpoint to cause the underlying Asterisk service to execute attacker-controlled commands.

Shadowserver first observed exploitation attempts targeting the vulnerability on September 9, 2026, making patching a priority for organizations operating internet-accessible Issabel systems.

CVE-2026-89026 at a Glance

Detail	Information
CVE	CVE-2026-89026
Product	Issabel Framework / Issabel PBX
Severity	Critical
CVSS v3.1	9.8
CVSS v4.0	9.3
CWE	CWE-321 – Use of Hard-coded Cryptographic Key
Authentication Required	No
User Interaction	No
Primary Impact	Arbitrary OS command execution
Execution Context	Asterisk service user
Exploitation	Observed in the wild
First Observed	September 9, 2026
Patch Released	August 1, 2026

The Root Cause: A Universal JWT Signing Secret

The vulnerability originates in the Issabel Framework's:

pbxapi/index.php

The affected implementation contains a hard-coded HS256 JWT signing key.

JWTs are commonly used by web applications and APIs to prove that requests have been authenticated and authorized.

Under normal circumstances:

User authenticates

↓

Server creates JWT

↓

JWT cryptographically signed

↓

Client sends JWT with API request

↓

Server verifies signature

↓

Request accepted

The security of this process depends heavily on keeping the signing secret protected.

Issabel's vulnerable implementation breaks that assumption because the same secret was embedded directly into the application and shared across vulnerable installations.

Once the secret becomes known, an attacker does not need to steal an administrator's password or compromise an existing account.

They can generate their own token.

How the Attack Works

The exploitation chain is relatively direct:

Attacker identifies vulnerable Issabel PBX

↓

Known hard-coded JWT secret obtained

↓

Attacker creates forged HS256 JWT

↓

Issabel accepts forged bearer token

↓

Attacker accesses PBX management API

↓

/pbxapi/manager/originate called

↓

System application parameter supplied

↓

Asterisk processes request

↓

Attacker-controlled OS command executes

The command runs with the privileges assigned to the Asterisk user account.

This is therefore better described as unauthenticated OS command execution than automatically claiming complete root compromise.

Additional privilege escalation would be required if the Asterisk account does not already possess elevated system privileges.

Why the manager/originate Endpoint Matters

The vulnerable attack path involves:

/pbxapi/manager/originate

The endpoint interacts with functionality associated with the Asterisk Manager Interface.

Asterisk supports an application called:

System

which can execute operating-system commands.

When an attacker combines a forged authentication token with access to this functionality, a legitimate PBX feature becomes a remote command-execution primitive.

The vulnerability therefore combines two dangerous conditions:

• Broken API authentication
• Powerful backend functionality
• Unauthenticated command execution

Why PBX Servers Are Valuable Targets

A compromised PBX system can provide attackers with access to much more than voice functionality.

Depending on configuration and permissions, an Issabel environment may contain or interact with:

• SIP credentials
• Extension information
• Call records
• Voicemail
• Contact information
• PBX configuration
• Call-routing rules
• Administrative credentials
• Internal network services
• Telephony infrastructure

A compromised PBX may also provide a foothold from which attackers attempt further reconnaissance or lateral movement.

Potential post-exploitation activity could include downloading malware, establishing persistence, stealing configuration data or abusing telephony resources. These are potential consequences of command execution rather than confirmed behavior in the currently observed exploitation campaign.

Active Exploitation Began Weeks After the Patch

The vulnerability was fixed on August 1, 2026.

Shadowserver subsequently began observing exploitation on:

September 9, 2026

That created a window of roughly five weeks between availability of the fix and publicly reported exploitation.

At the time of reporting, researchers had not publicly identified:

• The threat actor responsible
• Malware being deployed
• The number of compromised servers
• Victim organizations
• The attacker's ultimate objective
• Persistence mechanisms
• Data exfiltration activity

Therefore, the confirmed fact is active exploitation of the vulnerability, not a specific ransomware, espionage or botnet campaign.

How Issabel Fixed the Vulnerability

The August patch removes the universal JWT secret from the application code.

Instead of using the same embedded signing key across deployments, the corrected implementation retrieves the JWT key from:

/etc/issabel.conf

This removes the shared-secret condition that allowed attackers to create tokens valid across vulnerable installations.

Reports identify the relevant security fix with Issabel Framework commit:

b97dbaf0b71c1c36f841e672b664afbeb02773bd

Organizations should update to a Framework release containing that fix rather than relying solely on network mitigations.

Internet-Facing PBX Systems Face the Greatest Risk

Because exploitation does not require valid credentials or user interaction, externally accessible Issabel API endpoints present the most immediate exposure.

The attacker does not need:

A valid account

A stolen password

MFA approval

Phishing

Local system access

User interaction

Instead, the attacker needs network access to the vulnerable service and knowledge of the shared signing secret.

This makes public-facing vulnerable PBX servers particularly attractive targets for automated scanning and exploitation.

What Security Teams Should Hunt For

Organizations running Issabel should investigate historical activity rather than assuming that installing the patch automatically means the environment was never compromised.

Security teams should review:

• Web server access logs
• Issabel Framework logs
• Asterisk logs
• Requests to /pbxapi/manager/originate
• Unexpected bearer-token authentication
• Suspicious use of the System application
• Shell commands executed by the Asterisk account
• Unexpected child processes
• Newly downloaded binaries or scripts
• Suspicious files in temporary directories
• New scheduled tasks or cron jobs
• Unexpected outbound network connections
• Unauthorized changes to PBX configuration
• New users or SSH keys
• Unusual SIP configuration changes

Particular attention should be paid to activity occurring from September 9 onward, although reviewing an earlier period is appropriate for high-value or internet-exposed systems because public reporting only establishes when Shadowserver first observed exploitation—not necessarily the first time anyone exploited the vulnerability.

Watch the Asterisk Process Tree

Endpoint monitoring can also help identify suspicious post-exploitation activity.

Administrators should investigate unexpected command interpreters or download utilities launched in the context of Asterisk.

Examples worth investigating could include unusual execution involving:

/bin/sh

/bin/bash

curl

wget

python

perl

nc

These processes are not proof of compromise by themselves, but unexpected execution originating from PBX services can provide useful investigation context.

A suspicious process chain might resemble:

Asterisk

↓

Shell

↓

Download utility

↓

Unknown executable/script

↓

Outbound network connection

Such behavior should receive immediate investigation.

Restrict PBX Management Interfaces

Patching is the primary remediation, but organizations should also reduce unnecessary exposure of PBX management services.

Recommended controls include:

• Do not expose PBX administration interfaces directly to the internet unless required.
• Restrict API access using firewall rules.
• Use VPN-based administrative access.
• Implement IP allowlisting where practical.
• Segment PBX infrastructure from critical corporate systems.
• Restrict outbound connectivity from PBX servers.
• Monitor unusual command execution.
• Apply least privilege to service accounts.
• Centralize Issabel, Asterisk and operating-system logs.

A PBX server should not automatically have unrestricted network access simply because it needs to communicate with telephony infrastructure.

Already Vulnerable Systems Need Compromise Assessment

Because CVE-2026-89026 is already being exploited, administrators of previously vulnerable internet-facing systems should consider performing a compromise assessment, not simply installing the update.

A reasonable response process is:

Patch Issabel

↓

Confirm vulnerable code is removed

↓

Review historical API requests

↓

Examine Asterisk process activity

↓

Search for persistence

↓

Inspect unexpected files

↓

Review outbound connections

↓

Rotate exposed credentials if compromise is suspected

↓

Rebuild system if integrity cannot be established

If attackers successfully executed arbitrary commands before patching, removing the original vulnerability does not necessarily remove malware or persistence mechanisms they may have installed.

Why Hard-Coded Cryptographic Keys Are Dangerous

CVE-2026-89026 demonstrates why cryptographic secrets should not be embedded directly into software distributed to many customers.

Consider two designs.

Unique secrets:

Organization A → Key A
Organization B → Key B
Organization C → Key C

Compromise of Key A primarily threatens Organization A.

With a universal secret:

Organization A → Key X
Organization B → Key X
Organization C → Key X
Organization D → Key X

Once Key X becomes known, every unpatched deployment relying on it may become vulnerable.

For an open-source application, the risk is even clearer because embedded secrets may be visible directly in publicly accessible source code.

Security Takeaway

CVE-2026-89026 is a straightforward example of how a single cryptographic design mistake can undermine an application's entire authentication boundary.

Issabel Framework relied on a hard-coded JWT signing secret shared across vulnerable installations.

Once that key became known, an attacker could effectively manufacture their own authentication:

Known JWT Key

→ Forged Token

→ PBX API Access

→ Asterisk System Function

→ OS Command Execution

The vulnerability is especially serious because it requires no valid account and no user interaction, and exploitation has already been observed.

Organizations running Issabel should therefore treat remediation as more than a routine software update.

Patch the Framework, reduce external API exposure, review historical activity and investigate previously exposed systems for signs of compromise.

At present, the public evidence confirms exploitation of the vulnerability but does not establish who is behind the attacks, how many organizations have been compromised or what attackers are doing after obtaining command execution.