Falha crítica no Archon expõe agente de código com IA na rede sem senha; ainda não há versão corrigida

Uma falha crítica no Archon, ferramenta que orquestra agentes de código com inteligência artificial, permite que qualquer pessoa com acesso de rede envie comandos ao agente e execute código na máquina, sem precisar de senha. Publicada em 15 de outubro de 2026 com o identificador CVE-2026-111322, a vulnerabilidade recebeu nota 9,8 de 10 no CVSS 3.1, a faixa mais alta de gravidade, e atinge as versões 0.2.13 até 0.11.1, segundo os registros consultados. Nenhuma versão aparece nas fontes como corrigida.

O problema está na API de controle do projeto, exposta em /api/*. Conforme o registro da vulnerabilidade, essa API não faz nenhuma verificação de autenticação e, por padrão, escuta em 0.0.0.0 — ou seja, em todas as interfaces de rede da máquina, e não apenas no localhost. Quem alcança essa porta fala direto com o agente.

O que a falha crítica no Archon permite na prática

Execução de comandos no host, com o mesmo usuário que roda o Archon. De acordo com a descrição publicada, um atacante sem credenciais e com acesso de rede à instância pode enviar mensagens ao agente de codificação — e esse agente roda com bypassPermissions, o modo em que pedidos de confirmação são dispensados.

A classificação técnica é CWE-306, ausência de autenticação para função crítica. O impacto atinge os três pilares do CVSS: confidencialidade, integridade e disponibilidade. No CVSS 4.0, a nota é 9,3, também crítica. O cálculo considera ataque pela rede, sem privilégios prévios e sem interação do usuário, o que explica a pontuação tão alta.

Os registros descrevem a capacidade técnica da falha, não um ataque em curso: não há, nas fontes consultadas, relato de incidente, de exploração em massa ou de exploit público. O EPSS, índice que estima a probabilidade de exploração nos 30 dias seguintes, está em 0,69%, no percentil 51,9. É um número baixo, mas o índice estima a chance de exploração vista no mundo real, não a dificuldade técnica do ataque — e aqui a exploração é trivial para quem encontra a porta aberta.

Por que o padrão de escuta em 0.0.0.0 é o ponto sensível

Porque a mesma configuração inofensiva no notebook do desenvolvedor vira porta de entrada num servidor. Ferramentas de agente para desenvolvimento costumam ser desenhadas para rodar na máquina do próprio dev. Quando o padrão é escutar em todas as interfaces, o comportamento muda de significado no momento em que a ferramenta sobe numa VPS ou num contêiner com porta publicada: o que era “só a minha máquina” passa a ser qualquer um na mesma rede — ou na internet, se houver porta aberta e IP público.

É esse o cenário que o desenvolvedor brasileiro precisa checar hoje, antes de qualquer outra coisa. Muita gente sobe esse tipo de stack em VPS baratas para deixar o agente trabalhando fora do notebook.

Como checar se a sua instalação está exposta

São quatro verificações nas suas próprias instâncias e levam poucos minutos:

1. Liste as portas em escuta no host e procure por endereços 0.0.0.0 ou [::] associados ao processo do Archon:

ss -ltnp

2. Se a ferramenta estiver em contêiner, confira o mapeamento de portas. Publicação do tipo 0.0.0.0:porta->porta deixa o serviço acessível de fora:

docker ps --format '{{.Names}}\t{{.Ports}}'

3. Verifique a versão instalada e compare com a faixa afetada (0.2.13 a 0.11.1).
4. Teste de fora da máquina se a porta da sua instância responde. Se responder de outro host sem pedir credencial, considere a instância exposta.

O que fazer enquanto não houver versão corrigida

As medidas disponíveis são de rede e de configuração, não de código. A orientação genérica dos registros é atualizar para uma versão posterior à última afetada, mas 0.11.1 é ao mesmo tempo a última listada como afetada e a mais recente nas referências consultadas — não há patch indicado para aplicar agora.

Até que o projeto publique uma correção, dá para:

• restringir o serviço ao loopback (127.0.0.1) em vez de 0.0.0.0;
• não publicar a porta em contêineres;
• bloquear o acesso no firewall do provedor;
• usar túnel SSH ou VPN quando precisar alcançar a instância remotamente;
• rodar o agente com usuário sem privilégios e revisar o uso de bypassPermissions, o que reduz o estrago em caso de acesso indevido;
• desligar a instância, se ela não precisa ficar no ar agora.

Quem descobriu e o que vem a seguir

O crédito pela descoberta é de hieuPenguinnn, e as referências do registro apontam para o código de configuração de autenticação e de roteamento da API no repositório do projeto no GitHub. O CVE foi atribuído pela VulnCheck, o registro está com status “Deferred” e foi atualizado em 16 de outubro. A expectativa é que uma nova versão passe a exigir autenticação na API de controle e mude o endereço de escuta padrão. Até lá, o controle está do lado de quem hospeda.