Uma vulnerabilidade no OpenCode pode comprometer a segurança de desenvolvedores que utilizam o agente de inteligência artificial em ambientes Windows e Windows Subsystem for Linux (WSL). A falha está relacionada ao processamento inadequado de URLs durante a autenticação OAuth de servidores MCP, permitindo que entradas maliciosas sejam interpretadas como comandos pelo PowerShell.
O problema é especialmente preocupante porque uma operação aparentemente comum, como conectar uma ferramenta externa ao ambiente de desenvolvimento, pode abrir caminho para a execução de código arbitrário. Em determinadas condições, um servidor MCP malicioso pode explorar a maneira como o OpenCode solicita a abertura do navegador, transformando um procedimento de autenticação em um vetor de ataque.
Outro aspecto relevante é a ausência de um identificador CVE específico, o que dificulta a identificação da vulnerabilidade por ferramentas automatizadas de segurança. Para desenvolvedores, administradores de sistemas e profissionais de DevOps, compreender o funcionamento da falha e verificar a versão instalada do OpenCode são medidas importantes para reduzir a exposição.
Como funciona a vulnerabilidade no OpenCode no Windows e WSL
O OpenCode é um agente de programação assistida por inteligência artificial que permite interagir com projetos de software, analisar arquivos, executar tarefas e integrar ferramentas externas. Sua capacidade de automatizar operações no ambiente de desenvolvimento torna a segurança dessas integrações particularmente importante.
Uma das tecnologias utilizadas nesse ecossistema é o Model Context Protocol (MCP), protocolo que estabelece uma forma padronizada de conectar aplicações de IA a ferramentas, serviços e fontes de dados.
O MCP permite ampliar as funcionalidades de um agente, oferecendo acesso a recursos como repositórios, bancos de dados, APIs e serviços externos. Entretanto, essas integrações também introduzem novas superfícies de ataque, especialmente quando informações fornecidas por servidores externos são utilizadas em operações locais.
A falha identificada no OpenCode está relacionada ao processo de autenticação OAuth, mecanismo utilizado para autorizar o acesso a serviços sem compartilhar diretamente as credenciais do usuário com a aplicação cliente.
Durante esse procedimento, um servidor MCP pode fornecer uma URL de autorização que precisa ser aberta no navegador. O problema surge quando essa URL não recebe o tratamento adequado antes de ser encaminhada ao mecanismo responsável por iniciar o navegador no sistema operacional.
Em ambientes vulneráveis, caracteres especiais presentes na URL podem interferir na interpretação do comando utilizado para abrir o endereço.
Consequentemente, uma informação que deveria funcionar apenas como endereço de autenticação pode acabar sendo tratada como parte de uma instrução executável.
O papel do protocolo MCP e a injeção via PowerShell
O ponto central da vulnerabilidade está na interação entre o OpenCode, o mecanismo de autenticação OAuth e a função auxiliar utilizada pelo pacote open para abrir páginas no navegador.
No Windows, determinadas implementações desse procedimento dependem da execução de comandos por meio do PowerShell.
O PowerShell é uma ferramenta legítima de administração e automação do Windows, mas sua capacidade de interpretar comandos também exige cuidados rigorosos quando recebe informações de fontes externas.
Quando uma URL controlada por um servidor MCP malicioso é inserida em uma chamada ao shell sem o tratamento necessário, existe o risco de ocorrer uma injeção de comandos.
O fluxo de exploração pode ser compreendido em cinco etapas:
- O desenvolvedor configura ou utiliza um servidor MCP controlado por um agente malicioso.
- O OpenCode inicia um procedimento de autenticação OAuth para estabelecer a conexão.
- O servidor fornece uma URL de autorização contendo caracteres ou instruções especialmente preparados.
- O mecanismo de abertura do navegador encaminha o endereço para uma execução inadequadamente protegida no PowerShell.
- O sistema pode interpretar parte do conteúdo como um comando, permitindo a execução de código com os privilégios do processo afetado.
A exploração não depende necessariamente de o usuário abrir manualmente um arquivo executável suspeito. O próprio fluxo de autenticação pode funcionar como ponto de entrada.
Isso não significa, porém, que qualquer conexão MCP ou autenticação OAuth provoque automaticamente uma invasão. O cenário exige condições específicas, incluindo a utilização de uma implementação vulnerável e o fornecimento de uma URL maliciosa.
O impacto potencial inclui execução de comandos não autorizados, acesso a arquivos do projeto, exposição de credenciais e comprometimento do ambiente de desenvolvimento, conforme os privilégios disponíveis ao processo.
Por que macOS e Linux tradicional não foram afetados da mesma forma
A vulnerabilidade apresenta uma característica importante: seu mecanismo de exploração está associado à forma como o navegador é iniciado em ambientes Windows.
No macOS e em distribuições Linux executadas nativamente, a abertura de URLs utiliza mecanismos diferentes daqueles empregados no caminho vulnerável do Windows.
Em sistemas Unix, ferramentas de abertura de aplicativos e URLs podem utilizar chamadas específicas do sistema operacional, sem necessariamente passar pela mesma interpretação de comandos do PowerShell.
Essa diferença reduz a exposição ao vetor específico de injeção identificado.
Entretanto, o WSL exige atenção especial.
Embora permita executar aplicações Linux dentro do Windows, o WSL mantém mecanismos de interoperabilidade com o sistema hospedeiro. Dependendo da implementação utilizada, operações iniciadas no ambiente Linux podem recorrer a componentes do Windows.
Por isso, executar o OpenCode dentro do WSL não garante proteção contra essa vulnerabilidade.
É importante diferenciar a ausência desse vetor específico em determinadas plataformas de uma garantia geral de segurança. Outros problemas envolvendo servidores MCP, autenticação ou execução de ferramentas podem afetar diferentes sistemas operacionais.
Por que a vulnerabilidade no OpenCode sem CVE preocupa especialistas
Um dos aspectos mais delicados desse incidente é a ausência de um identificador oficial no sistema Common Vulnerabilities and Exposures (CVE).
Os identificadores CVE funcionam como referências padronizadas para vulnerabilidades conhecidas. Eles são utilizados por pesquisadores, fornecedores e plataformas de segurança para acompanhar falhas, relacionar produtos afetados e organizar processos de correção.
Em ambientes corporativos, scanners de vulnerabilidades frequentemente consultam bancos de dados associados a esses identificadores para detectar softwares desatualizados.
Quando uma falha não possui CVE, ela pode deixar de aparecer em verificações baseadas exclusivamente nesses registros.
Isso não significa que todas as ferramentas de segurança sejam incapazes de identificar o problema. Soluções que analisam versões, configurações, comportamento e indicadores de comprometimento podem detectar riscos mesmo sem um identificador CVE.
O principal desafio é que a ausência de um registro padronizado reduz a visibilidade da vulnerabilidade nos processos automatizados de gerenciamento de riscos.
A resposta da Anomaly e os limites de confiança dos servidores MCP
A desenvolvedora Anomaly, responsável pelo OpenCode, adotou uma interpretação relacionada aos limites de confiança estabelecidos entre a aplicação e os servidores MCP.
Segundo o posicionamento descrito sobre o incidente, servidores MCP externos são considerados componentes fora do limite de confiança da aplicação, uma distinção importante na avaliação da responsabilidade sobre entradas potencialmente maliciosas.
Essa interpretação está associada à decisão de não solicitar um identificador CVE específico para a falha.
Do ponto de vista da segurança de aplicações, entretanto, a existência de uma fonte externa não elimina a necessidade de tratar adequadamente os dados recebidos.
O princípio fundamental é que informações provenientes de componentes externos não devem ser interpretadas como comandos executáveis sem validação e separação apropriadas.
A situação também evidencia um desafio crescente no ecossistema de agentes de IA: estabelecer limites claros entre dados, instruções, permissões e operações locais.
Ferramentas de programação assistida por IA frequentemente possuem acesso a diretórios de trabalho, terminais, variáveis de ambiente e credenciais utilizadas no desenvolvimento.
Por esse motivo, uma falha em um componente de integração pode apresentar consequências maiores do que aquelas observadas em aplicações com permissões mais restritas.
Versões afetadas e relação com o CVE-2025-6514
O intervalo de versões apontado para a vulnerabilidade no OpenCode começa na 1.0.137 e se estende até a 1.18.32, com correção indicada a partir da 1.18.33.
Essa delimitação deve ser considerada na auditoria de instalações, inclusive quando o OpenCode estiver sendo executado dentro do WSL.
O incidente também apresenta semelhanças com o CVE-2025-6514, vulnerabilidade anteriormente identificada no projeto mcp-remote.
Ambos os casos demonstram como fluxos de autenticação e abertura de URLs podem representar riscos quando entradas externas alcançam mecanismos de execução de comandos.
Apesar das semelhanças, não se trata necessariamente da mesma vulnerabilidade. Os projetos possuem implementações próprias, e cada falha deve ser analisada de acordo com seu código, condições de exploração e versões afetadas.
A principal lição é que o protocolo MCP não deve ser tratado como uma garantia automática de segurança. A proteção depende também da implementação dos clientes, servidores e componentes auxiliares envolvidos.
Como corrigir a vulnerabilidade no OpenCode e proteger seu ambiente
A principal recomendação para usuários do Windows e WSL é atualizar imediatamente o OpenCode para a versão 1.18.33 ou superior.
A correção foi disponibilizada em 28 de setembro de 2026, após a comunicação privada da vulnerabilidade pelos pesquisadores da Pillar Security.
A atualização introduziu melhorias no tratamento das URLs e atualizou a dependência open da versão 10.1.2 para a 11.0.4.
Essa mudança é especialmente importante porque a versão corrigida da biblioteca modifica a forma como os endereços são encaminhados ao PowerShell, impedindo a interpretação indevida de expressões incorporadas às URLs.
A correção também adicionou verificações para permitir somente esquemas HTTP e HTTPS. Entretanto, essas verificações, isoladamente, não seriam suficientes, pois o ataque poderia utilizar um endereço HTTPS aparentemente válido.
1. Verifique a versão instalada
Abra o terminal do Windows, PowerShell ou ambiente WSL em que o OpenCode está instalado e execute:
opencode --versionCompare o resultado com as versões conhecidas:
| Versão do OpenCode | Situação no Windows e WSL |
|---|---|
| 1.0.137 até 1.18.32 | Vulnerável |
| 1.18.33 | Corrigida |
| Superior à 1.18.33 | Contém a correção |
Se a instalação estiver dentro do intervalo vulnerável, priorize a atualização.
2. Atualize o OpenCode
Para instalações realizadas globalmente pelo npm, utilize:
npm install -g opencode-ai@latestDepois, confirme a versão instalada:
opencode --versionQuem instalou o OpenCode por outros métodos deve utilizar o gerenciador de pacotes correspondente.
Em ambientes WSL, verifique também se existem instalações separadas no Windows e na distribuição Linux. Atualizar uma delas não garante que a outra tenha recebido a correção.
3. Audite os servidores MCP configurados
A atualização deve ser acompanhada de uma revisão das integrações utilizadas pelo agente.
Para listar os servidores MCP configurados, execute:
opencode mcp listExamine os serviços apresentados e identifique integrações desconhecidas, desnecessárias ou mantidas por terceiros sem garantias adequadas de segurança.
A análise deve considerar não apenas o nome do servidor, mas também sua origem, domínio, responsável pela manutenção e necessidade de acesso ao ambiente de desenvolvimento.
Servidores MCP que eram confiáveis no momento da configuração também podem se tornar perigosos posteriormente, especialmente em casos de comprometimento de infraestrutura ou perda de controle sobre domínios.
Caso não seja possível atualizar imediatamente, a medida preventiva é remover ou desabilitar servidores MCP remotos não confiáveis e evitar novas autenticações OAuth por meio dessas integrações até a aplicação da correção.
4. Revise possíveis sinais de comprometimento
A presença de uma versão vulnerável não significa que o computador tenha sido invadido.
Entretanto, organizações que utilizaram servidores MCP suspeitos devem considerar uma investigação adicional.
Essa análise pode incluir registros de execução do PowerShell, processos inesperados, alterações em arquivos sensíveis e atividades anormais envolvendo credenciais ou tokens de acesso.
Em ambientes corporativos, equipes de segurança também devem verificar instalações do OpenCode fora dos inventários tradicionais de software, especialmente em máquinas utilizadas para desenvolvimento e automação.
O que a falha revela sobre a segurança dos agentes de IA
O incidente evidencia que a segurança dos agentes de programação depende de muito mais do que impedir respostas perigosas produzidas por modelos de inteligência artificial.
Neste caso, a exploração ocorre em um componente convencional de software, responsável por abrir URLs durante a autenticação. Não é necessário manipular o modelo por prompt injection para alcançar o vetor vulnerável.
A Pillar Security atribuiu à falha uma pontuação proposta de 9,8 no CVSS 3.1, classificação crítica que representa o potencial de comprometimento da confidencialidade, integridade e disponibilidade do sistema. Essa pontuação é uma avaliação dos pesquisadores, não uma classificação oficial associada a um CVE.
A ausência de um identificador público reforça a necessidade de políticas de atualização que não dependam exclusivamente de alertas automatizados.
Para desenvolvedores que utilizam agentes de IA com acesso ao terminal, repositórios e serviços corporativos, a revisão das integrações MCP deve fazer parte da rotina de segurança.
A vulnerabilidade no OpenCode já possui correção, mas instalações antigas continuam representando um risco quando utilizadas nas condições afetadas.
Verifique agora a versão do OpenCode, atualize o software e revise seus servidores MCP. Compartilhar esse alerta com outros desenvolvedores e administradores que utilizam Windows e WSL também pode ajudar a reduzir a exposição de ambientes de desenvolvimento.
