Issabel PBX hardcoded JWT key enables unauthenticated code execution on exposed installs

What happened

Issabel Framework, an open-source unified communications platform built around Asterisk, shipped its pbxapi component with an HS256 signing secret embedded directly in the code. According to a dev.to write-up on the flaw, every installation used the identical value, meaning a single leaked string defeats authentication across the whole install base rather than on one server.

The bug is tracked as CVE-2026-89026, carries a CVSS base score of 9.8, and was addressed in upstream commit b97dbaf. Shadowserver recorded the first evidence of real-world exploitation on 9 September 2026, and proof-of-concept code is already public.

From forged token to command execution

The pbxapi layer accepts JSON Web Tokens signed with the shared secret. Because the platform is open source and the key sits in the code, an attacker who obtains the value can compute a valid HMAC signature with any scripting language and present a token the service trusts. No credentials and no prior foothold are needed; the only prerequisites are network reach to the pbxapi endpoint and the ability to sign a JWT.

The dev.to write-up explains that a valid token opens the door to the management originate function, which takes a System parameter and passes it straight to Asterisk. Asterisk then executes the supplied string with the privileges of its own process, converting the API into a remote code execution primitive that requires no user interaction.

Blast radius beyond telephony

A PBX is rarely an isolated appliance. The host carries dial plans, directory data, call detail records and recorded conversations, and often connects to CRM systems. Code execution on the Asterisk box lets an attacker rewrite call routing for toll fraud, listen to recordings and voicemail boxes, pull extension credentials and use the machine as a pivot into the surrounding network.

Asterisk typically runs under a dedicated low-privilege account, so full system takeover still depends on how the host is hardened. That nuance matters, but it offers limited comfort: the attacker begins with complete control inside the application context, which is a strong starting position for further escalation.

Remediation and verification

The recommended path is to apply the upstream fix, which removes the hardcoded key, and to rotate the signing secret on every instance, since the old value must be treated as compromised from the moment it became public. After upgrading, administrators should confirm that tokens signed with the previous key are rejected, that pbxapi is not reachable from untrusted networks, and that Asterisk logs covering the exposure window have been retained.

Post-incident checks include scanning call detail records for unexpected international destinations, hunting for manager accounts nobody set up, and searching for persistence mechanisms such as web shells or scheduled tasks. Where an upgrade cannot be scheduled right away, the dev.to write-up advises restricting pbxapi at the network layer, because the flaw needs no victim action and the API endpoint is all an attacker has to reach.

Why it matters

This is a textbook illustration of why symmetric secrets must never ship inside source code. One shared key turns a population of independently deployed servers into a single shared failure, and the flaw compounds the classic weak-authentication-plus-dangerous-function pattern: the hardcoded key alone would be bad, and the System passthrough alone would be bad, but together they yield unauthenticated remote code execution rated 9.8.

The public record also has limits worth stating plainly. The advisories do not quantify how many Issabel installations were internet-facing or how many were actually breached, and Shadowserver's sighting establishes that exploitation happened, not how widely. For any operator with an exposed pbxapi endpoint, the prudent assumption is that the period before patching deserves a full review.