- The Mess: Issabel shipped the same hard-coded HS256 JWT signing key in every installation. Attackers can forge their own authentication tokens and reach an Asterisk command-execution path without credentials.
- The Damage: A remotely reachable PBX can become an OS command-execution target, giving attackers control over the Asterisk process and potentially the entire telephony server.
- The Fix: Update the Issabel Framework to a build containing commit
b97dbafor later and investigate exposed systems for signs of exploitation.
One JWT key for everyone
CVE-2026-89026 is the kind of vulnerability that should never survive into production software.
The Issabel Framework used a hard-coded HS256 signing key inside the pbxapi component.
Worse, that key was identical across installations.
That means the cryptographic secret protecting JWT authentication was not actually a secret unique to the deployment.
Anyone who obtains the key can generate a token that the application considers valid.
And according to the CVE record, this does not require an account, privileges or user interaction. The vulnerability carries CVSS 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0.
The authentication boundary collapses first
The vulnerable component is Issabel’s pbxapi.
Normally, an attacker reaching a PBX API should have to authenticate before invoking privileged operations.
The hard-coded JWT secret breaks that assumption.
The attacker can create a forged HS256 bearer token and present it to the API.
The server verifies the signature using the same embedded secret.
The signature is valid.
The token is accepted.
There is no stolen password.
No brute force.
No phishing.
No existing account.
The attacker simply manufactures the credential the server trusts.
The next step is Asterisk
Forged authentication is only half of the problem.
The dangerous endpoint is:
pbxapi/manager/originate
The vulnerable request can reach Asterisk’s Manager Interface functionality and invoke the System application parameter.
That turns an authentication bypass into arbitrary operating-system command execution as the Asterisk user.
The attack chain is therefore brutally short:
Internet
→ forged JWT
→ pbxapi
→ manager/originate
→ Asterisk System
→ OS command execution
There is no second vulnerability required to complete that chain.
Why System matters
Asterisk’s System application is designed to execute a system command.
In a legitimate PBX deployment, that functionality can be useful for integrations and automation.
In an unauthenticated remote attack, it becomes something entirely different.
The attacker-controlled request crosses from the web/API layer into the operating system.
The resulting process runs with the privileges available to the Asterisk service account.
That is not necessarily equivalent to immediate root access.
But it is already enough to create a serious foothold.
From there, the actual impact depends on the server configuration, filesystem permissions, available binaries, credentials, integrations and local privilege boundaries.
This was not theoretical
The CVE record contains an unusually important detail:
Shadowserver observed exploitation evidence beginning September 9, 2026.
The CVE itself was published on September 15.
So the timeline is not:
vulnerability → disclosure → maybe somebody exploits it.
It is closer to:
exploitation observed → vulnerability disclosed → defenders catch up.
That makes exposed installations particularly interesting to attackers.
The vulnerability is also not listed as a CISA KEV entry at the time of this article, but that does not contradict the Shadowserver observation. KEV inclusion and independent exploitation telemetry are separate things.
The original code tells the whole story
The upstream patch makes the mistake painfully obvious.
The vulnerable code contained a literal JWT key:
da893kasdfam43k29akdkfaFFlsdfhj23rasdf
The patch removes that hard-coded value.
Instead, the framework reads pbxapijwtsecret from /etc/issabel.conf, Base64-decodes it and rejects the configuration unless it contains at least 32 random bytes.
The resulting key is then supplied to the JWT implementation.
That is the correct security model:
one installation → one secret → stored outside application source
rather than:
every installation → same secret → attacker can reproduce authentication
Why PBX infrastructure is an attractive target
A compromised web application is bad.
A compromised PBX can be worse.
A telephony server may sit at the intersection of:
- SIP infrastructure
- extensions
- call routing
- voicemail
- call recordings
- external trunks
- billing systems
- CRM integrations
- internal networks
- administrator interfaces
- API credentials
A successful attacker may therefore gain more than command execution.
Depending on the environment, the PBX can become a launch point for credential theft, network reconnaissance, call manipulation, data collection or lateral movement.
The exact post-exploitation impact depends on what the Issabel host can access.
But the initial foothold requires no legitimate user account.
Patch level is commit-based
There is an annoying operational detail here.
The CVE record describes the vulnerable range in terms of Git history:
affected before b97dbaf0b71c1c36f841e672b664afbeb02773bd
rather than providing a clean product-version range.
The official Issabel commit is therefore the important reference.
Its message is explicit:
“Use jwt key stored in conf file instead of using a hardcoded one.”
The patch changes pbxapi/index.php to require /etc/issabel.conf, retrieve pbxapijwtsecret, decode it and enforce a minimum 32-byte key length.
Administrators should verify that their deployed framework contains this change rather than relying solely on an ambiguous package version.
What to do if patching is not immediate
The primary fix is straightforward:
install a framework build containing b97dbaf or later.
If that cannot happen immediately, reduce exposure.
Do not leave the Issabel pbxapi interface directly reachable from the public Internet unless absolutely necessary.
Use:
- firewall restrictions
- VPN access
- IP allowlists
- reverse-proxy access controls
- network segmentation
The vulnerable API should be reachable only from systems that genuinely need it.
But this is a containment measure, not a replacement for the patch.
The JWT key is already compromised by design.
If the PBX was exposed, check it
Because exploitation was observed before public disclosure, patching alone should not be treated as proof that nothing happened.
Review:
- web-server access logs
- Issabel API requests
pbxapiactivity- Asterisk Manager Interface logs
- unexpected
originateoperations Systemapplication invocations- new or modified users
- modified dial plans
- suspicious cron jobs
- unexpected processes running as
asterisk - new SSH keys
- modified PHP files
- unusual outbound connections
- unexpected SIP activity
Pay particular attention to activity beginning around September 9, 2026, when Shadowserver first observed exploitation evidence.
If compromise is confirmed, treat the PBX as an incident rather than simply installing the patch.
Rotate secrets after remediation
The old JWT signing key must be considered compromised.
The upstream fix moves authentication to pbxapijwtsecret, generated and stored per installation.
After updating, review other credentials that may have been accessible from the PBX.
That includes:
- database credentials
- SIP credentials
- API tokens
- integration secrets
- SSH credentials
- cloud credentials
- CRM credentials
The exact rotation scope depends on what the Issabel host could access.
No exploit kit required
One particularly uncomfortable aspect of CVE-2026-89026 is how little an attacker needs to understand.
There is no exotic memory corruption.
No browser sandbox.
No complicated race condition.
No kernel exploit.
The vulnerability is essentially:
the server trusts a cryptographic key that everybody gets.
Once that key is known, the attacker can manufacture the authentication token.
Everything after that is application functionality doing exactly what it was programmed to do.
That is what makes hard-coded cryptographic secrets so dangerous in authentication systems.
Bugstoday’s take
This is a textbook example of how one bad secret-management decision can erase an entire authentication layer.
Issabel did not merely expose an API key.
It embedded the key responsible for validating JWTs directly into the application and shipped the same value to every installation.
The attacker doesn’t need to steal a password because the password is no longer the interesting credential.
The JWT signing key is.
And once that key is known, the API accepts the attacker’s forged identity and exposes an Asterisk command-execution path.
The most important detail is not even the 9.8 CVSS score.
It’s the timeline.
Shadowserver saw exploitation on September 9. The CVE was published September 15.
If you run Issabel and the PBX was Internet-facing, check the logs. Then patch it.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- Issabel Framework — official security fix commit b97dbaf
- CVE-2026-89026 — CVE record
- NVD — CVE-2026-89026
- VulnCheck advisory — Issabel PBX hard-coded JWT key RCE
