Hard-coded JWT key in Issabel Framework enables operating system command execution without authentication

A vulnerability CVE-2026-89026 has been discovered in the Issabel Framework web framework used to manage Asterisk-based PBX systems, allowing an unauthenticated remote attacker to execute arbitrary operating system commands. The cause is a hard-coded JWT (JSON Web Token) signing key that is identical across all framework installations. According to VulnCheck, an attacker can forge an authorization token and, via an Asterisk API endpoint, launch system commands. A patch is available in the project’s official repository — administrators are advised to apply it immediately.

Technical details of the vulnerability

Issabel Framework is an open-source web framework that integrates management modules for Asterisk-based IP telephony (PBX). The vulnerability affects the PBX API authentication mechanism: in the index.php file of the pbxapi component, the HS256 algorithm is used with a hard-coded secret key to sign JWT tokens. Since this key is identical across all installations, any attacker who knows its value can generate a valid bearer token without going through authentication.

As stated in the VulnCheck advisory, the attack chain is as follows:

1. The attacker crafts a forged JWT token using the known hard-coded signing key.
2. A request is made to the /pbxapi/manager/originate endpoint with this token.
3. An arbitrary OS command is passed in the System application parameter.
4. Asterisk executes this command as the Asterisk user.

Thus, exploitation requires neither credentials nor prior access to the system — network accessibility of the PBX API is sufficient. The range of affected versions is not specified in the available materials, which complicates assessing the scale of vulnerable installations.

Note: The CVSS v3.1 (9.8) and CVSS v4.0 (9.3) scores cited in the original report have not been independently confirmed through available NVD or CNA records.

Patch analysis

The fix published in the commit in the official repository addresses the root cause — the hard-coded secret is replaced with a key loaded from the /etc/issabel.conf configuration file. Analysis of the commit diff shows that the patch not only moves the key into configuration, but also introduces additional security checks:

• The pbxapijwtsecret parameter must be present in /etc/issabel.conf — if it is missing, PBX API initialization fails with a RuntimeException.
• The parameter value must be a Base64 string that decodes to at least 32 random bytes. If this condition is not met, the API will also not start.

This is an important operational nuance: simply updating the code is not enough. If, after applying the patch, there is no correctly generated secret in the configuration file, the PBX API will stop functioning. Administrators need not only to update the code, but also to generate a cryptographically strong key and set it in the configuration.

Information on exploitation

According to the original report, Shadowserver Foundation has observed attempts to exploit CVE-2026-89026 since 9 September 2026. However, this information was relayed via VulnCheck and has not been independently confirmed during verification against available primary sources. At the time of analysis, the vulnerability was not listed in the CISA Known Exploited Vulnerabilities catalog. There is no information about specific threat actors, victims, or the scale of the campaign.

Impact assessment

Issabel is used as a platform for enterprise and carrier PBX systems. Compromise of such a system can lead to:

• Execution of arbitrary commands on the telephony server with the privileges of the Asterisk user.
• Interception and manipulation of voice traffic.
• Use of the compromised server as a foothold for further movement within the network.
• Disruption of the organization’s telephony services.

PBX systems are often placed in network segments with weaker controls and may be accessible from the internet, which increases the attack surface.

Recommendations

1. Apply the patch from the official commit as soon as possible.
2. Generate a cryptographically strong secret — at least 32 random bytes encoded in Base64 — and set it as the pbxapijwtsecret value in the /etc/issabel.conf file.
3. Verify PBX API functionality after the update: make sure the API initializes correctly with the new key.
4. Restrict network access to the /pbxapi/ endpoint — it should not be accessible from the internet unless strictly necessary.
5. Audit logs for suspicious requests to /pbxapi/manager/originate, especially from unusual IP addresses.

Given how trivial the exploit is — a hard-coded key effectively turns authentication into a formality — there is no reason to delay the update. Even in the absence of confirmed widespread exploitation, the very fact that the key value and attack vector description are publicly available makes every unpatched Issabel Framework installation a potential target. Priority actions: update the code, generate a unique secret, and ensure that the PBX API is not accessible from untrusted networks.