Falha de autenticação no PraisonAI foi sondada horas após divulgação

CVE-2026-44338 expõe endpoints do servidor Flask legado do PraisonAI e permite enumeração de agentes ou execução de fluxos definidos em agents.yaml sem token.

Componente	Servidor de API Flask legado do PraisonAI em src/praisonai/api_server.py, usado pelo pacote Python afetado.
Vetor	Acesso de rede aos endpoints GET /agents e POST /chat em instâncias expostas, sem cabeçalho Authorization, devido a AUTH_ENABLED = False e AUTH_TOKEN = None.
Impacto	Enumeração do arquivo de agentes configurado, acionamento não autenticado do fluxo local em agents.yaml e exposição dos resultados de PraisonAI.run() ao chamador.
Prioridade	Atualizar para PraisonAI 4.6.34, retirar o servidor legado da exposição direta, revisar agents.yaml, auditar uso de provedores de modelo e rotacionar segredos referenciados pelo fluxo.
Versões	Afeta versões do pacote Python PraisonAI de 2.5.6 até 4.6.33; a correção está em 4.6.34.
Artefatos	CVE-2026-44338, src/praisonai/api_server.py, AUTH_ENABLED, AUTH_TOKEN, /agents, /chat, agents.yaml, PraisonAI.run().
IoCs	Sondagem observada a partir de 146.190.133[.]49 com User-Agent CVE-Detector/1.0, incluindo GET /agents sem autenticação.

Resumo técnico

CVE-2026-44338 é uma falha de ausência de autenticação no servidor de API Flask legado distribuído com o PraisonAI, um framework aberto para orquestração de múltiplos agentes. O problema não depende de força bruta, roubo de token ou exploração de corrupção de memória: a própria implementação enviada no pacote deixa a autenticação desativada por padrão, com AUTH_ENABLED = False e AUTH_TOKEN = None em src/praisonai/api_server.py. Quando esse servidor é iniciado e fica alcançável por rede, qualquer cliente capaz de abrir conexão HTTP com a aplicação pode consultar superfícies que deveriam ficar restritas ao operador do ambiente.

O impacto prático varia conforme o que foi configurado no agents.yaml, porque o endpoint vulnerável não concede sempre a mesma capacidade final em todos os ambientes. Em uma implantação simples, a exposição pode permitir enumeração da configuração de agentes por GET /agents. Em um ambiente com agentes integrados a provedores de modelo, ferramentas locais, conectores, credenciais ou automações internas, o risco passa a incluir execução não autenticada do fluxo por POST /chat e retorno dos resultados produzidos por PraisonAI.run() para o solicitante externo. A severidade CVSS informada é 7.3, mas a prioridade operacional deve considerar as permissões reais dos agentes configurados, os segredos disponíveis no processo e a exposição do serviço à internet.

A exploração começou a ser tentada poucas horas após a divulgação pública da vulnerabilidade. A atividade observada incluiu uma requisição GET /agents sem cabeçalho Authorization, usando User-Agent CVE-Detector/1.0, a partir de 146.190.133[.]49. A resposta 200 OK com dados do arquivo de agentes confirma a condição de bypass em instâncias vulneráveis e alcançáveis. Não foi observada, nesse conjunto específico de tentativas, chamada POST para /chat, o que caracteriza uma fase de verificação e identificação de alvos exploráveis, não necessariamente a execução completa de workflows.

Fluxo técnico

O fluxo vulnerável começa no servidor Flask legado incluído no pacote. A lógica esperada para uma API desse tipo seria validar um token antes de permitir acesso a rotas que expõem agentes ou disparam execução de workflows. No caso afetado, os controles de autenticação são neutralizados na configuração do próprio código enviado, e as variáveis responsáveis por habilitar a proteção e armazenar o token permanecem em estado que não exige credencial. Assim, a condição explorável aparece antes de qualquer validação de identidade: o roteamento HTTP recebe a chamada, processa a rota e entrega a funcionalidade ao cliente sem distinguir operador legítimo de origem não autorizada.

A rota /agents é relevante porque permite enumerar o arquivo de agentes configurado. Uma requisição GET /agents bem-sucedida pode retornar metadados como o arquivo agents.yaml e a lista de agentes carregados. Esse retorno pode revelar a estrutura operacional do ambiente, nomes de agentes, funções disponíveis, conectores usados e indícios de integrações com serviços externos. Mesmo quando a resposta não inclui segredos diretamente, a enumeração reduz incerteza para um atacante, porque confirma que a instância usa PraisonAI, que a rota está exposta, que a falha está presente e que existe um workflow configurado para possível acionamento posterior.

A rota /chat amplia o impacto porque permite acionar o fluxo local definido em agents.yaml. A consequência técnica não é fixa: se os agentes apenas respondem com conteúdo limitado, o dano pode ficar restrito a abuso computacional ou consumo de créditos de provedores de modelo. Se os agentes possuem ferramentas com acesso a arquivos, APIs internas, bancos de dados, sistemas de automação, repositórios ou segredos de ambiente, a execução não autenticada pode atravessar fronteiras de confiança do serviço e executar ações que o operador atribuiu aos agentes. A superfície de risco, portanto, é composta tanto pela falha de autenticação quanto pelas permissões concedidas à automação de IA.

A sequência observada no tráfego seguiu um perfil de scanner empacotado. Houve uma primeira passagem com caminhos genéricos associados a descoberta de exposição, incluindo /.env, /admin, /users/sign_in, /eval, /calculate e /Gemfile.lock. Uma segunda passagem, poucos minutos depois, direcionou requisições a superfícies ligadas a agentes de IA, incluindo PraisonAI. O pedido que corresponde diretamente a CVE-2026-44338 foi GET /agents sem autenticação. A ausência de chamadas para /chat indica que a atividade coletada priorizou confirmação de vulnerabilidade, mas a mesma condição técnica permitiria tentar execução do workflow em instâncias que permanecessem expostas.

Superfície afetada

A superfície afetada inclui implantações do pacote Python PraisonAI nas versões de 2.5.6 até 4.6.33 quando o servidor Flask legado está em uso e acessível por uma rede não confiável. A simples presença do pacote vulnerável em disco não prova exposição: o risco operacional exige que o componente de API vulnerável esteja iniciado, que as rotas estejam alcançáveis e que controles externos, como proxy reverso com autenticação, firewall, rede privada ou política de acesso, não bloqueiem o cliente não autorizado. Ainda assim, ambientes de laboratório, demonstração, instâncias temporárias, servidores de desenvolvimento publicados por túnel e workloads de IA em nuvem tendem a escapar de inventários tradicionais, o que torna a busca ativa necessária.

O arquivo agents.yaml é o ponto central para dimensionar impacto. Ele define o que os agentes podem fazer e quais integrações ficam disponíveis ao processo. Se houver chaves de API, nomes de provedores, referências a variáveis de ambiente, ferramentas locais, rotas internas ou automações com permissão elevada, a exposição da API deixa de ser apenas um problema de confidencialidade da configuração e passa a ser um caminho para abuso de execução. O operador deve avaliar também custos financeiros, porque chamadas não autorizadas a modelos podem gerar consumo em contas de provedores mesmo quando não há persistência ou movimentação lateral.

Instâncias expostas diretamente à internet exigem tratamento prioritário. A janela observada entre divulgação e primeira sondagem direcionada foi de poucas horas, com duas passagens espaçadas por cerca de oito minutos e volume aproximado de dezenas de requisições por passagem. Esse padrão mostra que a detecção pública de uma falha em projetos de IA menores pode ser incorporada rapidamente a scanners automatizados. A ausência de um nome de ator confirmado não reduz a urgência: a técnica é simples, o custo de exploração é baixo e a confirmação de vulnerabilidade exige apenas uma requisição HTTP sem token.

• Pacote Python PraisonAI de 2.5.6 a 4.6.33 com o servidor Flask legado iniciado.
• Endpoints /agents e /chat alcançáveis por redes não confiáveis ou pela internet.
• Ambientes em que agents.yaml referencia ferramentas, provedores de modelo, credenciais, variáveis de ambiente ou integrações internas.
• Serviços publicados sem autenticação externa em proxy reverso, gateway, balanceador, túnel de desenvolvimento ou regra de firewall restritiva.

Hunting e telemetria

A investigação deve começar nos logs HTTP do próprio serviço, do proxy reverso, do balanceador e dos controles de borda. Procure requisições para /agents sem cabeçalho Authorization, especialmente quando retornam 200 OK. Esse padrão é o sinal mais direto da enumeração não autenticada. Em seguida, revise chamadas para /chat, porque elas indicam tentativa de acionar o workflow configurado. Para cada evento, preserve horário, IP de origem, User-Agent, código de status, tamanho da resposta, método HTTP e corpo quando disponível. A comparação entre /agents e /chat ajuda a separar varredura de execução efetiva.

O indicador 146.190.133[.]49 e o User-Agent CVE-Detector/1.0 devem ser tratados como sinais úteis, mas não como cobertura completa. A vulnerabilidade é trivial de testar, e outros operadores podem alterar cabeçalhos, usar infraestrutura diferente ou encadear a requisição por provedores de nuvem. Regras de detecção não devem depender somente desses valores. Uma consulta robusta deve incluir qualquer acesso a /agents sem autenticação, qualquer POST /chat vindo de origem externa inesperada e sequências de descoberta que combinem caminhos genéricos como /.env com rotas específicas de agentes.

No endpoint, investigue o processo que executa o PraisonAI e os artefatos acessíveis ao usuário do serviço. Se houve chamada a /chat, correlacione o horário com logs de provedores de modelo, uso de tokens, requisições de saída, acesso a arquivos, chamadas a APIs internas e execução de ferramentas definidas no workflow. Em nuvem, revise grupos de segurança, regras de entrada, logs de VPC, logs de gateway e telemetria de egress para identificar comunicações incomuns iniciadas pelo host. Em CI/CD e repositórios, verifique se agents.yaml ou arquivos relacionados expõem nomes de segredos, variáveis ou endpoints que precisem de rotação.

• GET /agents sem Authorization, principalmente com resposta 200 OK e corpo contendo referência a agents.yaml.
• POST /chat originado de IP externo ou de cliente que não pertence à aplicação esperada.
• User-Agent CVE-Detector/1.0 e origem 146.190.133[.]49, sem limitar a detecção a esses artefatos.
• Sequências com /.env, /admin, /users/sign_in, /eval, /calculate, /Gemfile.lock e, depois, rotas de agentes.
• Aumento anormal de chamadas a provedores de modelo, consumo de créditos, requisições de saída ou execução de ferramentas no horário da exposição.

Mitigação

A primeira ação é atualizar o PraisonAI para 4.6.34 ou versão posterior que contenha a correção. Em paralelo, remova o servidor Flask legado da exposição direta enquanto a atualização é aplicada e validada. Se a API precisar continuar disponível, coloque o serviço atrás de autenticação obrigatória em camada externa, restrinja origem por rede e aplique regras explícitas para bloquear /agents e /chat a partir de clientes não autorizados. A mitigação não deve depender apenas de obscuridade de porta ou alteração de caminho, porque a falha está na ausência de autenticação do componente vulnerável.

Depois da correção, revise agents.yaml como um ativo sensível. Identifique quais agentes podem chamar ferramentas, acessar arquivos, invocar APIs, ler variáveis de ambiente ou consumir provedores de modelo. Remova permissões que não são necessárias, separe ambientes de desenvolvimento e produção, e reduza o privilégio do usuário que executa o processo. Quando houver referência a credenciais, chaves de API, tokens de provedor ou segredos usados por ferramentas, trate a exposição como potencial comprometimento e faça rotação. A revisão deve incluir caches, arquivos de configuração, variáveis de ambiente, gerenciadores de segredo e histórico de pipelines que possam ter propagado esses valores.

A validação defensiva precisa confirmar dois pontos: a rota /agents não deve retornar dados para chamadas não autenticadas, e /chat não deve disparar workflow sem identidade autorizada. Testes controlados devem ser executados a partir de uma origem equivalente à internet ou a uma rede não confiável, porque validações apenas locais podem mascarar controles de borda. Após bloquear a exploração, mantenha monitoramento retrospectivo desde a data de divulgação pública da falha e preserve evidências de qualquer acesso bem-sucedido. Se houver indício de chamada a /chat, a resposta deve avançar para análise de impacto sobre ferramentas acionadas, dados retornados e contas de provedores usadas pelo workflow.

• Atualizar o pacote para PraisonAI 4.6.34 e confirmar que versões de 2.5.6 a 4.6.33 foram removidas dos ambientes ativos.
• Bloquear exposição direta do servidor Flask legado e exigir autenticação em proxy, gateway ou camada equivalente antes de qualquer acesso à API.
• Revisar agents.yaml, reduzir permissões dos agentes e remover integrações que não sejam necessárias para o fluxo em produção.
• Rotacionar segredos referenciados pelo workflow, incluindo chaves de provedores de modelo e credenciais acessíveis ao processo.
• Auditar logs de /agents e /chat, custos de provedores de modelo, tráfego de saída e execução de ferramentas no período posterior à divulgação.
• Criar detecções para acesso não autenticado a rotas de agentes e para sequências de varredura que combinem caminhos genéricos com superfícies de IA.