Uma RCE crítica no IBM Langflow força a CISA a fixar um prazo de emergência — o mecanismo exato (dois endpoints encadeados) é precisamente o que acabámos de verificar que não existe no nosso próprio código
A 4 de agosto, a CISA inscreveu uma falha crítica do Langflow (CVSS 9.8) no seu catálogo de vulnerabilidades ativamente exploradas, com prazo de emergência a 7 de agosto para as agências federais americanas — ontem. O Langflow, adquirido pela IBM através da compra da DataStax, orquestra fluxos de trabalho de agentes de IA. Levámos esse gatilho a sério e verificámos o nosso próprio código contra exatamente este tipo de falha, no mesmo dia.
O mecanismo é simples e brutal: um atacante não autenticado chama o endpoint /api/v1/auto_login, que, na configuração por defeito (LANGFLOW_AUTO_LOGIN=true), entrega um token de superadministrador a qualquer chamador na rede. Com esse token, chama depois /api/v1/validate/code para executar código Python arbitrário via exec(). Nenhuma autenticação necessária — o exploit funciona numa instalação por defeito, sem configurar nada de especial. Circula código de prova de conceito desde julho, e foi observada exploração ativa no terreno. Não é um incidente isolado para a plataforma: a Forkast regista também a CVE-2026-33017 (RCE não autenticada, explorada 20 h após a divulgação) e a CVE-2026-55255 (uma falha IDOR usada para aspirar chaves de fornecedores LLM, credenciais cloud e segredos de base de dados) — um padrão repetido de falhas na fronteira de autenticação da pilha de infraestrutura agêntica.
O reflexo de marketing seria citar esta falha para dizer «vejam, os outros são vulneráveis, nós não». Preferimos verificar antes de escrever o que quer que fosse. Um grep completo de todo o nosso backend (server/src/*.ts) confirma: nenhum endpoint concede um token privilegiado sem autenticação — não existe nada equivalente a auto_login no nosso código. Os únicos 4 sítios onde o AppManager lança um processo externo (o chat do assistente, o motor de e-mails, o envio para a caixa «Enviados» e a transcrição de áudio via ffmpeg) passam todos os argumentos como array, nunca como string interpolada — a classe de injeção de shell que este tipo de falha costuma explorar não tem por onde entrar aqui. E sobretudo: o AppManager não expõe a nenhum utilizador um construtor visual de fluxos que execute definições arbitrárias carregadas — a própria arquitetura que torna o Langflow vulnerável a esta classe de falha não existe do nosso lado, não porque a tenhamos «protegido», mas porque não a construímos.
A favor da AppH
- A verificação não é uma afirmação vazia: é um grep real de todo o código servidor, feito no próprio dia da divulgação, e o raciocínio completo (que ficheiros, que chamadas, porque são seguras) está documentado no nosso próprio registo interno de decisões.
- A diferença de arquitetura é real, não cosmética: uma ferramenta que executa definições de fluxo carregadas pelo utilizador tem uma superfície de ataque que nós simplesmente escolhemos não construir.
Contra / o limite honesto
- Três falhas críticas em 2026 numa única plataforma de agentes mostram que toda a categoria é jovem e pouco testada — o nosso próprio código de invocação de agente (o chat do assistente) é igualmente recente e não recebeu o nível de escrutínio adversarial que uma ferramenta usada por milhares de empresas como o Langflow atrai naturalmente.
- Um grep que fazemos nós próprios não é uma auditoria de segurança independente — é um ponto de partida honesto, não uma certificação. Ninguém ter encontrado uma falha no nosso código não significa que não exista, apenas que ninguém procurou ainda com a intensidade que se vê sobre o Langflow.
A tentação, perante a atualidade de um concorrente a arder, é usá-la como prova de que fizemos bem. Preferimos ser honestos sobre o que esta verificação prova de facto: prova que olhámos, num dia concreto, com um método concreto, e que não encontrámos nada comparável — não que estejamos a salvo para sempre. A verdadeira lição do Langflow não é «evitem as ferramentas de agentes de IA», é que a fronteira entre «recomendar uma ação» e «executá-la» tem de continuar estanque mesmo sob a pressão de entregar depressa. No AppManager, o nosso assistente pode ler uma imagem que lhe envia ou lançar um processo para transcrever uma chamada — mas nenhuma dessas capacidades lhe dá o poder de modificar os seus dados de negócio ou de desencadear uma ação com consequência real sem que um humano a tenha validado primeiro. Continua a ser verdade hoje porque o verificámos hoje, não porque o decretámos uma vez e deixámos de olhar.
Verificado por um humano da AppH