OpenCode e MCP: uma URL de login não deve virar comando de shell
A falha de autenticação no OpenCode expõe a fronteira entre metadados remotos e execução local, além dos limites de scanners por CVE.
Uma falha no OpenCode permitia que um servidor MCP malicioso ou comprometido executasse comandos durante a autenticação OAuth em Windows e WSL.[6] As versões afetadas vão de 1.0.137 a 1.18.32, com correção na 1.18.33, publicada em 28 de setembro; Linux nativo e macOS não são afetados por esse caminho específico.[6]
O que muda para quem desenvolve
O endereço de autorização recebido do servidor era encaminhado a uma biblioteca que montava um comando PowerShell sem escape adequado.[6] O ataque dependia de iniciar a autenticação, não acontecia apenas por manter o servidor configurado.[6]
A falha coloca uma decisão de engenharia em evidência: dados necessários para abrir o navegador atravessaram uma fronteira e ganharam significado de código. Minha análise é que permitir um servidor MCP na configuração não deveria conceder a ele liberdade implícita para construir comandos locais.
A correção foi tratada pela Anomaly como refatoração, sem CVE nem aviso de segurança específico, enquanto a Pillar Security propôs gravidade 9,8.[6] Um inventário que só procura identificadores CVE pode não sinalizar esse caso. A versão efetiva da ferramenta precisa fazer parte da verificação.
Como aplicar
Atualize o OpenCode nos ambientes afetados e revise quais servidores remotos podem iniciar fluxos de autenticação. Não considere uma revisão antiga garantia permanente: a notícia observa que comprometimento posterior ou mudança de controle do domínio também pode criar a condição.[6]
Para integrações próprias, prefira abertura de navegador por mecanismos que não interpretem shell. Valide estrutura, esquema e destino esperado da URL, mas não use essa validação como substituta da passagem segura de argumentos. Uma URL ainda pode começar com HTTP ou HTTPS e carregar a entrada que dispara a injeção descrita.[6]
Como teste proposto, substitua o abridor de navegador por um componente falso em testes unitários. Alimente URLs sintéticas com caracteres especiais e verifique se continuam sendo um único dado, sem execução de processos. Repita o teste em cada sistema operacional suportado.
Cuidados e limites
A Pillar não relatou exploração conhecida nem publicou indicadores capazes de confirmar ataques anteriores.[6] Atualização corrige o caminho conhecido, mas não prova que uma máquina nunca foi atingida.
O problema é separado do incidente do OpenCode Console, que pode ter exposto chaves de provedores de IA.[6] Não misture resposta a vazamento de segredos com correção de injeção no login. Cada fronteira precisa de diagnóstico e evidência próprios.
Fonte
[6] Fonte: The Hacker News