Жёстко закодированный 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 недоступен из недоверенных сетей.