Issabel Framework: adesivo CVE-2026-89026 após exploração ativa

Uma vulnerabilidade grave no framework Web Issabel Framework — identificada como CVE-2026-89026 — está a ser explorada ativamente e permite que os atacantes remotos não autenticados executem comandos no sistema operacional do equipamento que corre Asterisk. A falha tem uma pontuação elevada de severidade (CVSS v3.1: 9.8; CVSS v4.0: 9.3) e baseia-se numa má gestão de chaves JWT: uma chave HS256 codificada de forma fixa e comum a todas as instalações permitia a um atacante fabricar tokens válidos e chamar a API de gestão para provocar a execução de comandos com o usuário asterisk.

Atos confirmados: a vulnerabilidade identificada como CVE-2026-89026 existe no ficheiro pbxapi index.php do Issabel Framework e usa uma chave HS256 codificada (“da893kasdfam43k29akdkfaFFlsdfhj23rasdf”) que é idêntica entre instalações; essa fraqueza permite forjar tokens bearer válidos e, através do endpoint /pbxapi/manager/originate com o parâmetro System application, provocar que Asterisk execute ordens do sistema com os privilégios do usuário asterisk. O fornecedor publicou uma correção em 1 de agosto de 2026 que substitui a chave incorporada por uma chave leída desde /etc/issabel.conf. Além disso, a fundação Shadowserver informou de observações de exploração ativa desde 9 de setembro de 2026. Estes pontos formam o núcleo do que está confirmado até agora.

Como funciona tecnicamente a falha: JWT com algoritmo HS256 usa uma única chave secreta compartilhada para assinar e verificar tokens. Se essa chave é conhecida ou idêntica em todas as instalações, qualquer pessoa que a conheça pode criar um token com os campos necessários para passar a autenticação baseada em bearer token. Em Issabel, o endpoint vulnerável permite iniciar uma chamada ou executar o aplicativo System em Asterisk; quando usado esse aplicativo, Asterisk executa comandos do sistema como o usuário asterisk. A combinação de token forjado + endpoint originate produz execução remota de comandos sem necessidade de credenciais válidas do sistema.

Quem está em causa: todas as instalações de Issabel Framework que não tenham sido atualizadas desde a correção de 1 de agosto de 2026 e que exponham o endpoint afetado (por exemplo, em interfaces públicas ou em redes com acesso externo) estão em risco. As PBX instaladas em ambientes mal segmentados, com portos HTTP/HTTPS expostos ou sem restrições de acesso à API, são as mais vulneráveis. Também estão em risco integrações que utilizem essa API para gestão remota e que assumam que o JWT é uma garantia de identidade segura.

As consequências práticas variam de acordo com a configuração, mas são relevantes: a execução de comandos como usuário asterisk permite modificar configurações de Asterisk, manipular arquivos de gravação, estabelecer persistência limitada (por exemplo, cronjobs sob permissões do usuário asterisk), implantar ferramentas de escuta ou relé de chamadas, mover lateralmente na rede se existirem privilégios adicionais, ou preparar etapas posteriores de escalada de privilégios. Estas consequências são plausíveis e devem ser tratadas como risco real, embora o alcance exato dos ataques observados (quem são os atacantes e quantas instalações foram comprometidas) não esteja documentado publicamente.

O que se sabe e o que não: é confirmado que a vulnerabilidade existe, que foi adesivo e que Shadowserver detectou exploração ativa a partir de 9 de setembro de 2026. Não existem informações públicas verificadas sobre a técnica exata de exploração empregada em campo, a motivação dos atacantes, indicadores de compromisso partilhados em larga escala, nem o número de instalações afectadas. É possível que os atacantes estejam a simular a descoberta de endpoints expostos para explorar instalações sem adesivos, mas isto é uma estimativa baseada no padrão típico deste tipo de falhas.

Acções imediatas e concretas a tomar por um responsável pelo sistema: atualize sem demora a versão de Issabel que contém a correção publicada em 1 de agosto de 2026; confirme que a instalação agora carrega uma chave JWT desde /etc/issabel.conf e que essa chave é única por servidor. Se não puder atualizar imediatamente, bloquee o acesso ao endpoint vulnerável a nível de firewall ou balanceador (filtrar /pbxapi/manager/originate e restringir o acesso HTTP/S ao painel de gestão apenas para IPs de confiança). Desactive a API se não for utilizada.

Além de atualizar e bloquear o acesso, implemente os seguintes passos operacionais: verifique os registros de acesso da Web e do Asterisk para itens para /pbxapi/manager/originate e verificações de Authorization: Bearer; inspeccione /var/log/asterisk/ e arquivos de sistema em busca de comandos invulgares executados pelo usuário asterisk e de novos arquivos ou cronjobs; corrobore a integridade de binários e configurações críticas; e, se for detectada atividade suspeita, considere a possibilidade de reconstruir o host afetado a partir de uma imagem conhecida limpa e restaurar configurações de backup verificados.

Para detecção e monitoramento concretes sugiro procurar padrões em logs: tentativas de acesso ao /pbxapi/manager/originate, presença de tokens bearer em cabeçalhos HTTP procedentes de origens não autorizadas, e comandos do sistema executados por processos filhos de Asterisk. Integre essas buscas em suas regras de IDS/IPS e em seu SIEM para alertas precoces.

Medidas de mitigação a médio prazo: assegure que as chaves JWT não estejam codificadas em código- fonte; favoreça o armazenamento seguro em ficheiros de configuração com permissões restritas ou em módulos de gestão de segredos. Aplique princípios de menor privilégio: reduza as permissões do utilizador asterisk tanto quanto possível; segmente a rede para que as interfaces de gestão do PBX sejam acessíveis apenas a partir de sub-redes administrativas; implemente autenticação forte para interfaces administrativas e auditoria obrigatória de alterações críticas.

Se você gerencia fornecedores ou clientes com PBX na nuvem, exija testes de adesivo e verificação e feche as APIs não usadas. As cópias de segurança e os testes de restauração devem fazer parte do plano de resposta, e ante indícios de compromisso agir como se tivessem obtido persistência e acesso lateral.

Para mais informações técnicas e boas práticas sobre o manejo de JWT e sua segurança veja as recomendações de OWASP sobre JSON Web Tokens e as páginas oficiais do projeto Issabel e Shadowserver: OWASP JWT Cheat Sheet, Issabel Project e Shadowserver Foundation. Estas fontes oferecem contexto adicional e orientações para ajustes operacionais e detecção.

Em resumo: é uma vulnerabilidade de exploração remota grave com patch publicado; a prioridade imediata é atualizar, bloquear o acesso à API afetada e procurar indicadores de compromisso em seus sistemas. Uma vez que a exploração ativa foi observada, trate as instalações expostas como de alto risco até confirmar a sua limpeza e isolamento.