One Key for Every PBX: The Issabel Framework Hardcoded JWT Flaw (CVE-2026-89026)

Issabel Framework, an open-source unified communications platform built around Asterisk, shipped with a single HS256 signing key hardcoded in its pbxapi component. Because every deployment used the same value, an attacker who learned it could mint a valid bearer token for any installation. The vulnerability is tracked as CVE-2026-89026, carries a CVSS base score of 9.8, and was fixed in commit b97dbaf.
Shadowserver reported its first exploitation evidence on 9 September 2026. Public proof-of-concept code exists.

How the token becomes a command

The pbxapi layer validates JSON Web Tokens signed with that shared secret. With the key known, an attacker generates a token the service accepts and calls the management originate function. That interface passes a System parameter through to Asterisk, which executes the supplied string with the privileges of the Asterisk process.
No credentials are needed and no prior access is required. The attacker needs network reach to the pbxapi endpoint and the ability to compute an HMAC, which any scripting language provides.

Why the impact extends past the phone system

A PBX is not an isolated appliance. It sits on the network with a dial plan, a directory, call detail records and often an integration path into customer relationship systems. Code execution on the Asterisk host gives an attacker the ability to modify call routing for toll fraud, read recorded calls and voicemail, harvest extension credentials, and use the host as a foothold for lateral movement. Asterisk commonly runs as a dedicated low-privilege user, so privilege escalation depends on the surrounding host configuration. The initial access is already full code execution in the application context.

Remediation and verification

Apply the upstream fix that removes the hardcoded key and rotate the signing secret on every instance, because a fixed key is compromised once it is public. After the upgrade, verify that tokens signed with the old key are rejected, that the pbxapi endpoint is not reachable from untrusted networks, and that Asterisk logs are retained for the exposure window. Review call detail records for unusual international destinations, check for unexpected manager accounts, and confirm that no scheduled task or web shell was left behind.
Where an upgrade cannot be scheduled immediately, restrict pbxapi access at the network layer, since the flaw requires no user interaction and the endpoint is the entire attack surface.

Limits of the public record

The public advisories do not quantify how many installations were reachable or how many were compromised. Shadowserver's observation establishes that exploitation occurred, not its scale. The severity score describes the flaw in the abstract, and local exposure depends on whether pbxapi faces the internet.

References

• NVD record for CVE-2026-89026.
• Upstream Issabel Framework fix commit b97dbaf.
• Shadowserver exploitation observation, 9 September 2026.
• VulnCheck advisory on the Issabel PBX flaw.