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

What the vulnerability actually is

Issabel Framework, the web-based administration layer for the open-source Issabel unified-communications PBX (an Asterisk/FreePBX-family project), shipped with a hard-coded HS256 JWT signing key embedded directly in pbxapi/index.php. Because the same key is compiled into every installation, it does not need to be leaked from a specific target — it is effectively public the moment one copy of the source is examined.

That single fact breaks the authentication model entirely. An attacker who knows the key can mint their own valid bearer tokens for any Issabel instance, without ever authenticating. Using a forged token, they can call the /pbxapi/manager/originate endpoint with the Asterisk System application parameter, which causes Asterisk to execute arbitrary operating-system commands with the privileges of the asterisk user — full unauthenticated remote code execution, tracked as CVE-2026-89026 and rated CVSS v3.1 9.8 / CVSS v4.0 9.3.

Why one hard-coded secret is catastrophic

This is a textbook case of hard-coded cryptographic material (CWE-798): the flaw isn't a logic bug that needs a crafted payload, it's a design choice that quietly discards the entire point of signing tokens. JWT signatures are only meaningful if the signing key is secret and unique per deployment; ship the same key to every customer and the token becomes trivially forgeable by anyone who reads the code once. Fixing this class of bug always requires rotating the secret, not just patching a code path — which is exactly what Issabel's fix does.

Timeline: patch first, exploitation second

Issabel pushed a fix on August 1, 2026 that replaces the shared hard-coded key with a per-installation key stored in /etc/issabel.conf. The vulnerability was reported by VulnCheck. Roughly five and a half weeks after the patch was available, the Shadowserver Foundation first observed active exploitation in the wild, starting September 9, 2026. As of the September 16 disclosure, there is no public detail yet on the scale of exploitation or who is behind it.

What operators should do now

• Update Issabel Framework to a version built from or after commit b97dbaf0b71c1c36f841e672b664afbeb02773bd, which stores the JWT signing key in /etc/issabel.conf instead of the source file.
• Treat any pre-patch instance as potentially compromised: rotate the signing key on upgrade and review Asterisk/system logs for command execution as the asterisk user that you can't attribute to legitimate call flows.
• Audit logs for calls to /pbxapi/manager/originate, particularly ones using the System application, as a specific indicator of this exploitation path.
• Remove pbxapi and other Issabel management interfaces from direct internet exposure; put them behind a VPN or IP allowlist regardless of patch status — internet-facing PBX admin panels are a recurring target category.

The bigger pattern

This isn't the first time a hard-coded key or default credential in unified-communications software has led to full-server compromise, and it won't be the last — PBX platforms sit at a privileged network position (telephony, often paired with broad OS access for call routing) that makes them attractive once exposed. Any organization running Issabel, or evaluating similar open-source UC platforms, should treat hard-coded-secret findings as immediate, all-fleet-affecting incidents rather than routine CVEs, since the same key compromises every unpatched deployment simultaneously.