Жорстко закодований JWT-ключ в Issabel Framework дозволяє виконувати команди ОС без автентифікації

У вебфреймворку Issabel Framework, що використовується для керування PBX-системами на базі Asterisk, виявлено вразливість CVE-2026-89026, яка дозволяє віддаленому зловмиснику без автентифікації виконувати довільні команди операційної системи. Причина — жорстко закодований ключ підпису JWT (JSON Web Token), однаковий в усіх інсталяціях фреймворку. За даними VulnCheck, зловмисник може підробити токен авторизації і через API-ендпойнт Asterisk запустити системні команди. Патч доступний в офіційному репозиторії проєкту — адміністраторам рекомендується застосувати його негайно.

Технічні деталі вразливості

Issabel Framework — вебфреймворк з відкритим вихідним кодом, що об’єднує модулі керування IP-телефонією (PBX) на базі Asterisk. Вразливість зачіпає механізм автентифікації PBX API: у файлі index.php компонента pbxapi використовується алгоритм HS256 із жорстко закодованим секретним ключем для підпису JWT-токенів. Оскільки цей ключ ідентичний в усіх інсталяціях, будь-який зловмисник, який знає його значення, здатен згенерувати валідний bearer-токен без проходження автентифікації.

Як повідомляється в бюлетені VulnCheck, ланцюжок атаки виглядає так:

1. Зловмисник формує підроблений JWT-токен, використовуючи відомий жорстко закодований ключ підпису.
2. З цим токеном виконується запит до ендпойнта /pbxapi/manager/originate.
3. У параметрі System application передається довільна команда ОС.
4. Asterisk виконує цю команду від імені користувача Asterisk.

Таким чином, експлуатація не потребує ані облікових даних, ані попереднього доступу до системи — достатньо мережевої доступності PBX API. Діапазон уражених версій у доступних матеріалах не зазначено, що ускладнює оцінку масштабу вразливих інсталяцій.

Примітка: оцінки CVSS v3.1 (9.8) та CVSS v4.0 (9.3), наведені у вихідному звіті, не були незалежно підтверджені через доступні записи NVD або CNA.

Аналіз патча

Виправлення, опубліковане в коміті офіційного репозиторію, усуває кореневу причину — жорстко закодований секрет замінюється ключем, що завантажується з конфігураційного файлу /etc/issabel.conf. Аналіз diff’у коміту показує, що патч не просто переносить ключ у конфігурацію, а й запроваджує додаткові захисні перевірки:

• Параметр pbxapijwtsecret має бути присутнім у /etc/issabel.conf — за його відсутності ініціалізація PBX API завершується помилкою (RuntimeException).
• Значення параметра має бути рядком у Base64, який декодується щонайменше в 32 випадкові байти. Якщо ця умова не виконується, API також не запуститься.

Це важливий операційний нюанс: простого оновлення коду недостатньо. Якщо після застосування патча в конфігураційному файлі відсутній коректно згенерований секрет, PBX API припинить функціонувати. Адміністраторам необхідно не лише оновити код, а й згенерувати криптографічно стійкий ключ і прописати його в конфігурації.

Відомості про експлуатацію

За даними вихідного звіту, Shadowserver Foundation зафіксувала спроби експлуатації CVE-2026-89026, починаючи з 9 вересня 2026 року. Втім, ця інформація передана через VulnCheck і не була незалежно підтверджена під час верифікації за доступними первинними джерелами. Вразливість на момент аналізу не внесено до каталогу CISA Known Exploited Vulnerabilities. Відомості про конкретних зловмисників, жертв або масштаб кампанії відсутні.

Оцінка впливу

Issabel використовується як платформа для корпоративних та операторських PBX-систем. Компрометація такої системи може призвести до:

• виконання довільних команд на сервері телефонії з правами користувача Asterisk;
• перехоплення та маніпуляції голосовим трафіком;
• використання скомпрометованого сервера як опорної точки для подальшого просування мережею;
• порушення роботи телефонного зв’язку організації.

PBX-системи нерідко розміщуються в мережевих сегментах із послабленим контролем і можуть бути доступні з інтернету, що збільшує площу атаки.

Рекомендації

1. Застосуйте патч із офіційного коміту якомога швидше.
2. Згенеруйте криптографічно стійкий секрет — щонайменше 32 випадкові байти, закодовані в Base64, — і пропишіть його як значення pbxapijwtsecret у файлі /etc/issabel.conf.
3. Перевірте працездатність PBX API після оновлення: переконайтеся, що API коректно ініціалізується з новим ключем.
4. Обмежте мережевий доступ до ендпойнта /pbxapi/ — він не має бути доступним з інтернету без нагальної потреби.
5. Проведіть аудит логів на предмет підозрілих звернень до /pbxapi/manager/originate, особливо з нетипових IP-адрес.

З огляду на тривіальність експлуатації — жорстко закодований ключ фактично перетворює автентифікацію на формальність — відкладати оновлення не слід. Навіть за відсутності підтвердженої масової експлуатації сам факт публічної доступності значення ключа та опису вектора атаки робить кожну непатчену інсталяцію Issabel Framework потенційною мішенню. Пріоритетна дія: оновити код, згенерувати унікальний секрет і переконатися, що PBX API недоступний з ненадійних мереж.