CVE-2026-89026, assessed at 9.8 under CVSS v3.1 and 9.3 under CVSS v4.0, allows an unauthenticated remote attacker to execute arbitrary operating-system commands against Issabel Framework installations.
How CVE-2026-89026 enables remote OS command execution
The flaw stems from a hard-coded HS256 JSON Web Token (JWT) signing key embedded in the Issabel Framework pbxapi index.php file. According to VulnCheck, that key is "identical across every installation, allowing unauthenticated remote attackers to forge valid bearer tokens." An attacker who forges such a token can call the manager endpoint /pbxapi/manager/originate and set the System application parameter; that call "caus[es] Asterisk to execute arbitrary OS commands as the Asterisk user." In short: a universal, baked-in JWT secret removes the need to authenticate, and the framework exposes an endpoint that will hand off supplied parameters to the underlying Asterisk instance.
Patch and mitigation: August 1, 2026 fix
The Issabel project pushed a corrective update on August 1, 2026. The patch replaces the hard‑coded JWT key — identified in the code as "da893kasdfam43k29akdkfaFFlsdfhj23rasdf" — with a JWT secret sourced from the local configuration file /etc/issabel.conf. That change moves the signing key out of application code and into a per‑installation configuration file, removing the identical‑across‑installations weakness that made token forgery straightforward.
VulnCheck and the advisory language recommend applying the latest fixes to obtain optimal protection; the published correction is the specific remediation offered by the Issabel update.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleObserved exploitation: Shadowserver Foundation, September 9, 2026
The Shadowserver Foundation was the first organization to observe active exploitation of CVE-2026-89026, reporting sightings on September 9, 2026. Beyond that initial detection, the available reporting contains no public details about how attackers are weaponizing the flaw in specific operations, who is responsible, or the scale of the activity. The presence of observed exploitation, however, moves this issue from theoretical to operational risk for any unpatched installations.
What this means for technologists and affected enterprises
- Technologists and security teams: Because the vulnerability relies on a universally identical, hard‑coded JWT key, any unpatched Issabel Framework instance is potentially vulnerable to token forgery and remote command execution. Teams should prioritize applying the August 1, 2026 patch that relocates the JWT key into /etc/issabel.conf and, where possible, verify that the configuration no longer contains the hard-coded value "da893kasdfam43k29akdkfaFFlsdfhj23rasdf."
- Affected enterprises and Issabel users: Organizations running Issabel Framework should treat the vulnerability as high severity — the published CVSS scores are 9.8 (v3.1) and 9.3 (v4.0) — and apply the available fixes. The combination of an exploitable endpoint (/pbxapi/manager/originate) and the potential for Asterisk to execute arbitrary OS commands as the Asterisk user elevates the consequences for business operations and telephony infrastructure.
The factual record in this advisory is compact but consequential: a hard‑coded, identical JWT signing key enabled unauthenticated remote command execution; a vendor patch was issued on August 1, 2026 to remove the hard‑coded key and source the secret from /etc/issabel.conf; and the Shadowserver Foundation observed exploitation on September 9, 2026, with no further public details about attribution or scope. For any organization running Issabel Framework, the concrete next step contained in the public record is straightforward — apply the published fixes to eliminate the identical, hard‑coded secret and reduce the risk of remote token forgery and OS command execution.
