CVE-2026-89026 is a hard-coded HS256 JWT signing key in the Issabel Framework, the web framework behind Issabel PBX. NVD scores it CVSS 3.1 base 9.8, and the key is identical across every installation — so the secret that is supposed to make a session token unforgeable is, in practice, public knowledge the moment anyone reads the source.
The exploitation status here is not CISA-backed, and that distinction matters. VulnCheck’s KEV catalog listed this CVE on September 15, 2026; CISA’s Known Exploited Vulnerabilities catalog does not list it as reflected in our ingestion through September 16, 2026. That means no Binding Operational Directive 26-04 remediation obligation attaches to this CVE — BOD 26-04 follows a CISA KEV listing, not exploitation as such. Federal agencies reading this should not treat it as a directive item.
What the flaw is
Per NVD, versions of the Issabel Framework before commit b97dbaf ship a hard-coded HS256 signing key in the PBX API. Because every installation uses the same key, an unauthenticated remote attacker can produce bearer tokens the API accepts as genuine. NVD classifies this under CWE-321, use of a hard-coded cryptographic key.
The consequence is not limited to API access. A forged token reaches a call-origination function that can be directed to run an operating-system command, which Asterisk then executes as the Asterisk service account. NVD’s vector, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, reflects that: network-reachable, no privileges, no user interaction, full impact across confidentiality, integrity and availability.
The remediation is a code update. This is worth stating plainly because hard-coded-secret findings often suggest an operator workaround — rotate the key, change the config — and there is none here. The key lives in application source, so the fix is the upstream commit, delivered through an Issabel Framework update.
On the exploitation claim
Two things in our ingested data speak to exploitation, and they may not be independent of each other.
NVD’s own description states that exploitation evidence was first observed by the Shadowserver Foundation on September 9, 2026 — six days before the VulnCheck listing. Separately, VulnCheck’s KEV catalog flags the CVE as exploited. On its face that is two sources.
The caution: NVD’s description text is supplied by the CVE Numbering Authority, and the reference list NVD carries for this CVE includes a VulnCheck advisory. The two may share an origin, in which case the corroboration is thinner than it looks. We have no way to establish independence from our data, so we are assigning this record medium confidence rather than high — a single real source with no contradicting evidence, per our confidence model, and not the two-source agreement that would earn high.
What we are not doing is discounting it. A dated third-party observation attributed to a named organization is a materially stronger exploitation signal than a bare catalog flag, and nothing in our data or in public reporting contradicts it. The honest statement is that exploitation is reported and plausible, not that it is confirmed by two independent sources.
Why this matters
The argument for patching this urgently does not rest on the exploitation report, and it is worth separating the two.
It rests on reach. A signing key shared across every deployment converts an authentication control into a formality — there is no per-install secret for an attacker to obtain first, no credential to phish, no prior foothold required. That is the PR:N in the vector doing real work rather than describing a theoretical edge case. Combine it with what an Issabel PBX is — telephony infrastructure, frequently exposed for remote administration or SIP access, running with service-account privileges on a host inside the network — and the exposure profile is severe on the merits.
Quietlytic covered a comparable defensive failure in a different product class earlier this month: Kestra OSS’s CVE-2026-49869, KEV-listed on September 2, 2026, was an authentication bypass in a request filter. The root causes are not alike — one is a filter that can be talked out of applying, the other a signing key that was never secret — but they share the property that actually determines exposure: neither requires an attacker to obtain anything installation-specific first. Where that holds, the authentication layer is not a control, and a version update is the only thing that restores it.
What we don’t have
- No CISA KEV listing as reflected in our ingestion through September 16, 2026. This is a scoped statement about our data, not a claim that CISA has assessed and declined to list the CVE.
- No EPSS score in our ingested data.
- CVSS is single-sourced — the 9.8 comes from NVD alone, with no second source scoring it.
- No version ranges. The only affected-version marker in our data is “before commit
b97dbaf,” which is a source-tree reference rather than a release number. Operators will need to map that to their installed build. - Exploitation corroboration may not be independent, as set out above.
Frequently Asked Questions
What is CVE-2026-89026?
A critical (CVSS 9.8) use of a hard-coded cryptographic key (CWE-321) in the Issabel Framework before commit b97dbaf. The HS256 JWT signing key in the PBX API is identical across every installation, letting unauthenticated remote attackers forge valid bearer tokens and reach functionality that runs operating-system commands as the Asterisk user.
Is CVE-2026-89026 being actively exploited? It is reported as exploited, with an important qualification. VulnCheck’s KEV catalog listed it on September 15, 2026, and NVD’s description records exploitation evidence first observed by the Shadowserver Foundation on September 9, 2026. CISA’s KEV catalog does not list it as reflected in our ingestion through September 16, 2026, and the two available sources may not be independent of each other — so we rate confidence medium rather than high.
Does BOD 26-04 require federal agencies to remediate CVE-2026-89026? No. BOD 26-04 obligations follow a CISA KEV listing, and this CVE is not on CISA’s catalog as reflected in our data. The severity and unauthenticated reach still make it a high-priority patch on their own merits.
How is CVE-2026-89026 fixed?
Through an Issabel Framework update containing commit b97dbaf. Because the key is embedded in application source rather than per-install configuration, there is no operator-side rotation or configuration change that remediates it.
Data sourced from the National Vulnerability Database (NVD) and VulnCheck KEV, aggregated September 18, 2026. Upstream fix: IssabelFoundation/framework commit b97dbaf. See more vulnerability intelligence.