CVE-2026-89026: Hard-Coded JWT Key Enables RCE on Issabel PBX

A hard-coded cryptographic key in the Issabel Framework allows unauthenticated remote code execution on PBX phone systems. The Shadowserver Foundation confirms active exploitation.

On September 9, 2026, the Shadowserver Foundation detected active exploitation against the Issabel Framework, an open-source web framework for PBX phone systems. The vulnerability CVE-2026-89026, caused by an identical hard-coded HS256 JWT key in every installation, allows an unauthenticated remote attacker to forge valid tokens and execute arbitrary system commands via the Asterisk call management APIs. The flaw was patched on August 1, 2026, but the exposure window of over five weeks left room for an in-the-wild attack campaign.

Key Takeaways

The hard-coded JWT key da893kasdfam43k29akdkfaFFlsdfhj23rasdf in the file pbxapi/index.php is identical across every Issabel Framework installation, making authentication token forgery trivial.
Forged tokens allow invocation of the /pbxapi/manager/originate endpoint with the System application parameter, causing OS command execution as the Asterisk user.
The official patch, released August 1, 2026, replaces the hard-coded key with a unique key stored in /etc/issabel.conf; the commit is b97dbaf0b71c1c36f841e672b664afbeb02773bd.
Active exploitation was confirmed by the Shadowserver Foundation starting September 9, 2026: no actor attribution, specific vector, or numerical scale of attacks is available.

How a Hard-Coded Key Defeats Authentication

The issue resides in the file pbxapi/index.php, where the JWT signing key da893kasdfam43k29akdkfaFFlsdfhj23rasdf is hard-coded in the source code. The key is identical in every instance of the framework, regardless of the user or organization that installed it. This architectural choice, classified as CWE-321 (Use of Hard-Coded Cryptographic Key), nullifies the JWT mechanism itself, which relies on the secrecy of the signing key to guarantee token authenticity.

An attacker who knows the key — and now anyone with access to the repository or analysis publications does — can generate valid JWT tokens without possessing legitimate credentials. According to VulnCheck analysis cited by The Hacker News: "The Issabel Framework 'contains a hard-coded HS256 JWT signing key in the pbxapi index.php file that is identical across every installation, allowing unauthenticated remote attackers to forge valid bearer tokens'". The step from public information to working exploit is technically immediate: no user interaction, no prior access requirement, no dependency on specific network conditions.

From Forged Token to System Command Execution

With a valid JWT token, the attacker accesses the /pbxapi/manager/originate endpoint, normally used to initiate phone calls via the Asterisk API, the open-source PBX engine underlying the Issabel Framework. The endpoint accepts parameters that define the call origin, destination, and application to execute. Among these parameters is System application, which allows specifying an executable command on the host operating system.

The mechanism is described precisely in the same analysis: "Attackers can use the forged token to call the manager '/pbxapi/manager/originate' endpoint with the System application parameter, causing Asterisk to execute arbitrary OS commands as the Asterisk user". The Asterisk process, which in standard configurations runs with dedicated but operationally significant privileges within the system, becomes the vehicle for arbitrary command execution. The result is unauthenticated Remote Code Execution with a fully remote vector and minimized attack conditions.

According to the CVE-2026-89026 record published on CVE.org and NVD, severity is rated CVSS 9.8 in version 3.1 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), confirming network attack, low complexity, no privileges required, and high impact on confidentiality, integrity, and availability. OffSeq Radar reports the CVSS 4.0 score at 9.3, consistent with the critical severity of the vulnerability.

The Timeline: August 1 Patch, September 9 Exploitation

The patch resolving the flaw was released on August 1, 2026. Commit b97dbaf0b71c1c36f841e672b664afbeb02773bd, verifiable on public repositories, implements the fundamental architectural change: the hard-coded key is removed from source code and replaced by a key generated and stored in the configuration file /etc/issabel.conf, presumably unique per installation. This separation between code and cryptographic secret represents the standard remediation for CWE-321.

Despite the patch availability, in-the-wild exploitation was observed starting September 9, 2026, as reported by the Shadowserver Foundation and confirmed by multiple primary sources. The interval of over five weeks between fix release and first active attack sighting indicates a significant exposure window for organizations that did not apply the update promptly. No source documents the presence of public exploits prior to the sighting date, nor provides indications on the nature of the first targets.

CVSS 9.8: remote, unauthenticated, low complexity, total impact on system confidentiality, integrity, and availability.

Immediate Actions

Verify the presence of the Issabel Framework in the inventory of Internet-exposed assets, with particular attention to PBX systems with remote access on standard or non-standard HTTP/HTTPS ports.
Immediately apply the August 1, 2026 patch contained in commit b97dbaf0b71c1c36f841e672b664afbeb02773bd, which replaces the hard-coded key with a local configuration key in /etc/issabel.conf.
Check access logs for the /pbxapi/manager/originate endpoint to identify anomalous requests with the System application parameter before September 9, 2026 or after, particularly from unrecognized IP addresses.
Isolate unpatchable PBX systems from direct Internet access until the fix is applied, given that the vulnerability is actively exploited and requires only network connectivity to the web interface.

Why PBX Systems Are a Forgotten Perimeter

PBX phone systems, especially in open-source configurations like Issabel, frequently represent a blind spot in organizational attack maps. Installed to manage voice communications, they often expose web administration interfaces to the Internet for remote management convenience, without the same security attention given to traditional production servers. Compromise of a PBX is not limited to call interception: the Asterisk process operates in tight integration with the underlying operating system, and the ability to execute arbitrary commands opens scenarios for lateral movement toward internal network segments.

The CVE-2026-89026 case also illustrates a recurring pattern in open-source infrastructure software: the ease of installation, achieved by embedding default keys and configurations in code, translates into a homogeneous and amplified attack surface. When the same cryptographic key is present on thousands of independent installations, discovery of the flaw equals simultaneous compromise of the entire unpatched installed base. The absence of automatic rotation mechanisms or first-boot key generation, as implemented in the August patch, signals that the initial design did not consider the threat model of distributed and potentially exposed installations.

The dossier does not specify whether detailed indicators of compromise are available, nor does it document post-exploitation objectives or threat actors. The lack of these elements limits the ability to assess the real scale of impact, but does not reduce the technical severity of the flaw: a system with the hard-coded key is not designed to resist, and proof that someone has begun exploiting it is confirmed.

Frequently Asked Questions

How do I know if my Issabel system is vulnerable?

Verify the installed version against commit b97dbaf0b71c1c36f841e672b664afbeb02773bd. If the file pbxapi/index.php still contains the key da893kasdfam43k29akdkfaFFlsdfhj23rasdf in plaintext, the system is vulnerable regardless of the declared version.

Does exploitation require special conditions?

No. The attack is fully remote, requires no authentication or user interaction, and has been confirmed in-the-wild with these minimal conditions. The only prerequisite is reachability of the framework's web interface.

What is the risk if I cannot update immediately?

The dossier does not document alternative mitigations. The only verified fix is the official patch. Prolonged exposure of an unpatched system to a vulnerability with confirmed active exploitation carries risk of complete compromise of the underlying operating system.

Information has been verified against cited sources and updated at time of publication.

Sources

Sources and references

Get DeafLetter