Threat Intelligence Report — CVE-2026-89026

Classification: Critical | Prepared for: valtersit.com — Enterprise Security Teams, SOC, Penetration Testers Report status: UNPATCHED vulnerability — active exploitation in the wild reported

Executive Summary

CVE-2026-89026 is a critical (CVSS 9.8) authentication bypass affecting the Issabel Framework, the web framework underpinning Issabel PBX. A hard-coded HS256 JWT signing key embedded in the pbxapi index.php file is identical across every installation, enabling any unauthenticated remote attacker to forge valid bearer tokens and reach privileged telephony APIs. Once authenticated with a forged token, an attacker can invoke the manager originate endpoint with the System application parameter, causing Asterisk to execute arbitrary OS commands as the Asterisk user — full remote code execution. The Shadowserver Foundation first observed exploitation evidence on 2026-09-09, indicating the flaw is being actively abused against internet-exposed PBX systems.

Technical Analysis

The vulnerability is rooted in CWE-321 (Use of a Hard-coded Cryptographic Key). The Issabel Framework ships a JSON Web Token signing secret directly in the pbxapi index.php source file. Because HS256 is a symmetric algorithm, the same secret is used both to sign and to verify tokens. When that secret is (a) embedded in distributable source, and (b) identical across every deployment, the trust model of the token-based authentication layer collapses completely.

The attack mechanism proceeds as follows:

1. Key disclosure. An attacker obtains the hard-coded HS256 secret from the distributed Issabel Framework source (pbxapi index.php). No live access to the victim is required to learn the key — the value is the same on every installation.
2. Token forgery. The attacker locally crafts a JWT with an arbitrary payload and signs it with the known secret using HS256. The resulting token is indistinguishable, to the server, from a legitimate bearer token, because the server verifies signatures with the same static key.
3. Authorization bypass. The forged bearer token satisfies the framework's authentication check, granting the attacker access to privileged API functionality that should require legitimate credentials.
4. Command execution via Asterisk. The attacker calls the manager originate endpoint with the System application parameter. In Asterisk's Manager interface, the System application is designed to run shell commands on the host. Passing attacker-controlled input through this parameter causes the server to execute arbitrary operating system commands as the Asterisk user.

The chain is fully unauthenticated from the attacker's perspective (AV:N, PR:N, UI:N), with no complexity barrier (AC:L) because the cryptographic secret is a fixed, publicly derivable value. Confidentiality, Integrity, and Availability are all rated High (C:H/I:H/A:H) — consistent with an attacker obtaining shell-level control over the PBX host.

It is important to note that insufficient public technical detail is available beyond the NVD description: the exact API route structure, request body schema, and token claim layout are not published. The above analysis is derived strictly from the vulnerability class (hard-coded symmetric JWT key) and the endpoints explicitly named in the description (pbxapi index.php, manager originate, System).

Exploitation Scenarios

No public proof-of-concept exists in tracked sources (PoC: None, Nuclei: None, Exploit Code: None). The following chain is inferred from the vulnerability class and the NVD description — specific request parameters and payload syntax are not published and are therefore not fabricated here.

1) Reconnaissance / target identification. An attacker scans the internet for internet-facing Issabel PBX management interfaces. Because the flaw affects every installation equally, any reachable instance is a candidate. Discovery is typically done with HTTP fingerprinting (titles, product strings, the pbxapi path) using tools such as Shodan, Censys, or mass internet scanning.

2) Triggering the flaw class (forge a token). Using the known, static HS256 signing secret that ships in pbxapi index.php, the attacker constructs a JWT locally and signs it with HS256. No account, credential, or prior foothold is required — the forged token is accepted because the server validates signatures against the same hard-coded key present in every deployment.

3) Payload / execution method. Armed with the forged bearer token, the attacker issues an authenticated request to the manager originate endpoint, supplying the System application parameter. Asterisk's Manager System application executes the supplied command on the host, resulting in OS command execution as the Asterisk user.

4) Post-exploitation impact. Command execution as the Asterisk user provides a foothold on the PBX host. From there an adversary can pivot into internal networks, intercept or redirect voice traffic, harvest configuration and credentials, install persistence, and use the PBX as a beachhead for lateral movement. Given the CVSS C:H/I:H/A:H rating, the operator should assume full compromise of the PBX host and its data.

Exploitation evidence was first observed by the Shadowserver Foundation on 2026-09-09; consistent with a mass-exploitation pattern typical of hard-coded-credential/key flaws where a single universal key unlocks the entire installed base.

Impact Assessment

• Affected systems: All Issabel PBX deployments whose Issabel Framework predates commit b97dbaf — i.e., every installation carrying the static HS256 key. Because the key is identical fleet-wide, exposure is effectively all internet-reachable instances.
• CVSS 9.8 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H. Network-reachable, no privileges, no user interaction, low complexity → trivially automatable at scale.
• Confidentiality (High): Forged tokens grant access to privileged telephony APIs; host access exposes configs, credentials, and call data.
• Integrity (High): Arbitrary OS command execution as the Asterisk user allows modification of system state and call behavior.
• Availability (High): An attacker with command execution can disrupt, disable, or re-purpose telephony services.
• Blast radius: PBX systems frequently sit at the boundary between IT and OT/telecom infrastructure. Compromise can extend beyond the host to voice networks, internal segments reachable from the PBX, and downstream users who trust the phone system.
• Business impact: Toll fraud, eavesdropping/telephony manipulation, network pivoting, data theft, and regulatory exposure. PBX compromise historically carries high financial cost via premium-rate abuse and service outage.

Detection Guidance

No public PoC/template exists; the rules below target the vulnerability class — forged/static-secret HS256 bearer tokens and abuse of Asterisk Manager System execution — and should be tuned to your environment.

Sigma Rule

title: Suspicious Issabel PBX API Access with Forged JWT and Asterisk System Execution
id: 9c1f2a44-7b6e-4d2a-9f3b-issabelcve202689026
status: experimental
description: Detects access to the Issabel pbxapi/manager originate endpoint with bearer JWT authentication, and Asterisk commands invoking the System application, consistent with CVE-2026-89026 exploitation.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-89026
author: valtersit.com Threat Intelligence
date: 2026/09/10
tags:
  - attack.t1190
  - attack.execution
logsource:
  category: webserver
  product: apache
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/pbxapi'
      - 'manager/originate'
      - 'action=originate'
  selection_auth:
    cs-uri-query|contains: 'action=originate'
    cs-uri-query|contains: 'Application=System'
  selection_agent:
    cs(User-Agent)|contains:
      - 'python-requests'
      - 'curl'
      - 'Go-http-client'
  condition: selection_uri and (selection_auth or selection_agent)
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - cs(User-Agent)
falsepositives:
  - Legitimate administrative PBX provisioning tools
level: critical

YARA Rule

rule CVE_2026_89026_Issabel_Hardcoded_JWT_Key
{
    meta:
        description = "Detects Issabel Framework pbxapi index.php containing a hard-coded HS256 JWT signing key (CVE-2026-89026)"
        author = "valtersit.com Threat Intelligence"
        date = "2026-09-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-89026"
        cve = "CVE-2026-89026"

    strings:
        $php = "<?php"
        $api = "pbxapi"
        $hs256_a = "HS256"
        $hs256_b = "hs256"
        $jwt_a = "JWT"
        $jwt_b = "jwt"
        $key_a = "secret"
        $key_b = "SECRET_KEY"
        $key_c = "SIGNING_KEY"
        $key_d = "signing_key"
        $encode = "encode("

    condition:
        filesize < 1MB and
        $php at 0 and
        $api and
        ( $hs256_a or $hs256_b ) and
        ( $jwt_a or $jwt_b ) and
        ( $key_a or $key_b or $key_c or $key_d ) and
        $encode
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-89026 Issabel PBX Asterisk Manager System Command Execution Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"pbxapi"; http.uri; content:"originate"; http.request_body; content:"System"; http.request_body; content:"originate"; http.header; content:"Authorization|3a| Bearer"; classtype:attempted-admin; reference:cve,CVE-2026-89026; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-89026; sid:202689026; rev:1;)

Note: the rule intentionally matches only the endpoint/parameter tokens named in the advisory (pbxapi, originate, System, Authorization: Bearer). Deploy in IDS mode first to baseline legitimate manager originate traffic before enabling blocking.

Elastic Detection

sequence by source.ip with maxspan=30s
  [ network where http.request.method == "POST"
      and url.path : "pbxapi*"
      and http.request.headers : "Bearer *" ]
  [ network where http.request.method == "POST"
      and url.path : "*originate*"
      and http.request.body : "*System*" ]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined OR sourcetype=bluecoat:proxysg:access
| eval uri = coalesce(uri, cs_uri_stem, url)
| eval qs  = coalesce(query, cs_uri_query, url_query)
| where (like(uri, "%pbxapi%") OR like(qs, "%pbxapi%"))
        AND (like(qs, "%originate%") OR like(uri, "%originate%"))
        AND like(qs, "%System%")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(uri) as uri values(qs) as query values(src_ip) as attacker
        by host
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="issabel,cve-2026-89026,web,">
  <rule id="2026890" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <id>31100</id>
    <match>pbxapi</match>
    <regex type="pcre2">(?i)(originate).*(System)</regex>
    <description>CVE-2026-89026: Issabel PBX manager originate System execution attempt detected</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack,exploit_attempt,</group>
  </rule>

  <rule id="2026891" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <id>31100</id>
    <match>pbxapi</match>
    <regex type="pcre2">Authorization:\s*Bearer\s+[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+</regex>
    <description>CVE-2026-89026: Bearer JWT presented to Issabel pbxapi endpoint</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack,exploit_attempt,</group>
  </rule>
</group>

Additional detective signal: monitor Asterisk process lineage. Any shell/child process spawned by the asterisk user (e.g., sh -c, bash, curl, wget, nc) is highly anomalous and should raise a high-severity alert — this is the observable consequence of the System application parameter.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No vendor patch, advisory, workaround, or fixed version has been identified from any tracked source. Commit b97dbaf of the Issabel Framework is referenced in the description as the boundary before which the flaw exists, but no released build or vendor confirmation is available. Treat all tracked installations as vulnerable.

1) Immediate mitigations (assume no patch exists):

• Remove network exposure. Do not leave Issabel PBX management/API interfaces reachable from the internet. Restrict pbxapi and Asterisk Manager access to trusted management networks, a VPN, or an authenticated reverse proxy.
• Block the named abuse path at the edge. WAF/reverse-proxy rules that reject requests to manager originate carrying the System application parameter, or that deny bearer-token access to pbxapi from untrusted sources, buy time (defense-in-depth, not a fix).
• Rotate the signing key if the secret is configurable. If your deployment allows the hard-coded HS256 key to be overridden via configuration, replace it with a strong, unique, per-installation secret immediately. Where it is not overridable, this is not possible and network isolation is mandatory.
• Hunt for prior compromise. Search web/proxy logs for pbxapi, originate, and System patterns; review Asterisk child-process activity; audit for unauthorized Manager sessions and new accounts.

2) Patch / upgrade steps:

• Track the Issabel Framework project for a commit or release at/after b97dbaf that replaces the hard-coded key. No such release is confirmed at the time of writing.
• When a fix lands: upgrade the Issabel Framework, then rotate the JWT signing key and invalidate any tokens issued under the old static key.
• Verify the fix by confirming the signing secret is no longer a static value embedded in pbxapi index.php and is unique per installation.

3) Long-term hardening:

• Eliminate hard-coded secrets from distributable source (CWE-321); externalize keys via environment/secret stores generated per deployment.
• Enforce unique, per-installation cryptographic material and support key rotation.
• Apply network segmentation between PBX/telephony systems and general IT; never expose PBX management planes to the internet.
• Monitor Asterisk Manager commands and host process lineage continuously; alert on System application usage.
• Integrate this CVE into SBOM/vulnerability management and watch FIRST.org for an EPSS score (not yet published) and CISA KEV for a future listing.

References

1. NVD — CVE-2026-89026: https://nvd.nist.gov/vuln/detail/CVE-2026-89026
2. MITRE CWE-321 — Use of Hard-coded Cryptographic Key: https://cwe.mitre.org/data/definitions/321.html
3. MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
4. Shadowserver Foundation — first observation of exploitation evidence, 2026-09-09 (public scanning/telemetry reporting): https://www.shadowserver.org/
5. FIRST.org EPSS — check for scoring updates (unscored at time of writing): https://www.first.org/epss/
6. CISA Known Exploited Vulnerabilities Catalog — not currently listed; monitor for addition: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Exploit-in-the-wild status: Exploitation evidence was first observed by the Shadowserver Foundation on 2026-09-09. No named threat actor or campaign attribution is available in the provided data. Given the universal, static key and the mass-scanning signal, operators should assume opportunistic, internet-wide exploitation and act on the isolation mitigations above immediately.

Report generated by valtersit.com Threat Intelligence. Technical claims are derived strictly from the supplied CVE data; where public detail is absent, the vulnerability class is described rather than fabricated implementation specifics. Verify all mitigations against your environment.