3 pontos por GN⁺ 2026-01-13 | 1 comentários | Compartilhar no WhatsApp
  • Foi descoberta uma vulnerabilidade crítica de execução remota de código em versões antigas do OpenCode, permitindo executar código arbitrário sem autenticação
  • Versões anteriores à v1.1.10 executam automaticamente um servidor HTTP e esse servidor permite execução de comandos arbitrários, leitura de arquivos e criação de sessões de terminal sem qualquer processo de autenticação
  • Antes da v1.0.216, apenas visitar um site já bastava para que código fosse executado no ambiente local do usuário
  • Na versão mais recente (v1.1.10), o servidor passou a vir desativado por padrão, mas ainda não há autenticação quando ele é ativado
  • A vulnerabilidade foi registrada como CVE-2026-22812, e desenvolvedores e usuários precisam atualizar e revisar as configurações imediatamente

Visão geral da vulnerabilidade

  • OpenCode é um assistente de programação com IA de código aberto e, antes da v1.1.10, ao ser executado iniciava automaticamente um servidor HTTP (porta padrão 4096+)
    • O servidor fornece endpoints como POST /session/:id/shell, POST /pty, GET /file/content
    • Como não existe autenticação, qualquer cliente capaz de se conectar pode executar código com os privilégios do usuário
  • Não há indicação visual para o usuário quando o servidor está em execução, o que dificulta perceber a exposição
  • A política de CORS é hardcoded como *.opencode.ai, então páginas servidas em opencode.ai ou seus subdomínios conseguem acessar a API do servidor
    • Se esse domínio for comprometido ou tiver uma vulnerabilidade de XSS, todos os usuários com o servidor ativo podem se tornar alvo de ataque

Vetores de ataque

  • Antes da v1.0.216: qualquer site podia executar código na máquina local de um usuário com OpenCode em execução
  • Antes da v1.1.10: processos locais ou páginas em localhost podiam executar código sem autenticação
  • Em todas as versões, quando o servidor está ativado:
    • Processos locais e páginas em localhost podem executar código sem autenticação
    • Com a flag --mdns, todos os dispositivos da rede local podem acessar
    • Não há indicação de que o servidor está em execução, então o usuário pode não perceber que está exposto
    • É possível executar código a partir do domínio opencode.ai ou de seus subdomínios

Exemplos de ataque (Proof of Concept)

  • Ataque local: com o servidor em execução, um processo local pode criar uma sessão com o comando curl e depois executar id > /tmp/pwned.txt
  • Ataque via navegador (antes da v1.0.216): uma página web pode enviar comandos ao servidor local via requisições fetch, baixar e executar scripts remotos
    • Funcionamento confirmado no Firefox; no Chrome, a proteção de acesso à rede local pode exibir uma janela de confirmação ao usuário

Medidas para usuários

  • Verifique a versão com opencode --version e atualize para a v1.1.10 ou superior
  • Confira no arquivo de configuração se server.port ou server.hostname estão ativados
  • Não use a flag --mdns (ela faz bind em 0.0.0.0 e expõe para toda a rede)
  • Se for realmente necessário usar o servidor, evite acessar opencode.ai e seus subdomínios
  • Tenha em mente que, com o servidor ativo, processos locais podem acessá-lo sem autenticação

Cronograma de divulgação

  • 2025-11-17: primeiro relato por e-mail, sem resposta
  • 2025-12-27: envio do GitHub Security Advisory, sem resposta
  • 2025-12-29: outro usuário fez um relatório público
  • 2025-12-30: aplicada restrição de CORS na v1.0.216
  • 2026-01-09: servidor desativado por padrão na v1.1.10
  • 2026-01-11: divulgação completa

Ações recomendadas

  • Restringir o CORS ao conjunto mínimo de domínios necessários (aplicado na v1.0.216)
  • Desativar o servidor por padrão (aplicado na v1.1.10)
  • Adicionar autenticação a todas as requisições ao servidor
  • Fornecer indicação clara ao usuário quando o servidor estiver em execução
  • Documentar que a opção --mdns faz bind em 0.0.0.0
  • Aplicar TLS nas comunicações de rede
  • Publicar oficialmente o GitHub Security Advisory e o CVE-2026-22812
  • Reforçar o monitoramento do e-mail de reports de segurança e dos alertas de GHSA
  • Esclarecer a relação de confiança entre mantenedores do OpenCode, opencode.ai e usuários

Referências

  • CVE: CVE-2026-22812
  • Pacote afetado: npm opencode-ai
  • Informações mais recentes e contato: cy.md

1 comentários

 
GN⁺ 2026-01-13
Comentários do Hacker News
  • Como mantenedor, reconheço que não lidamos bem com esta resposta ao relatório de segurança
    Com o uso crescendo rapidamente, os problemas se acumularam, e nesta semana planejamos nos reunir com especialistas para avançar com um programa de bug bounty e uma auditoria de segurança

    • Em vez de gastar dinheiro com bug bounty ou auditorias, deveria haver investimento em reestruturação organizacional e treinamento da equipe
      É mais importante que todo o time entenda e coloque em prática o guia OWASP sobre Insecure Design
    • No começo eu vi isso de forma positiva, mas preocupa o fato de que os responsáveis pelo relato da vulnerabilidade entraram em contato várias vezes e não receberam resposta
      Como o OpenCode é um agente de programação open source conhecido, existe a possibilidade de isso já ter sido explorado
      Acho que, mesmo agora, é necessário rodar o modelo em um ambiente de sandbox como o gVisor
      Se não houver uma resposta rápida, mais atacantes podem passar a mirar vulnerabilidades de RCE
    • O projeto parece ter crescido rápido demais, a ponto de gestão organizacional ter se tornado mais importante do que desenvolver código
      Fico curioso se vocês também estão se guiando por algo como princípios anarquistas de organização
    • Não dava simplesmente para pedir ao Claude para corrigir o problema de segurança?
    • É bom ver alguém compartilhando a situação com franqueza e assumindo responsabilidade. Não é fácil fazer isso, então agradeço
  • Muita gente está executando ferramentas como o OpenCode em ambiente local sem separação de privilégios
    Os plugins também são projetados por padrão assumindo acesso irrestrito, e o consumo de recursos é alto
    No mínimo, é melhor rodar isso dentro de um dev-container ou VM e conectar apenas os arquivos necessários via SSHFS ou Samba
    Se isso for incômodo, também dá para usar um VPS de 5 dólares por mês

    • Queria saber se alguém pode explicar de forma concreta como configurar um dev-container ou VM
    • O Claude pede solicitação de permissão a cada execução, então nesse ponto ele é um pouco mais seguro
    • Como sandbox para IA, o sprites.dev da fly.io é bem interessante
      Para rodar servidor com qemu, recomendo o quickemu
      O recurso de SSH remote do zed também é útil, então dá para usar Claude Code ou OpenCode junto
  • A correção de CORS impediu o abuso por sites externos, mas o problema estrutural é que o localhost consegue executar código
    O Neovim usa socket de domínio por padrão, e o daemon SSH do VS Code tem procedimento de autenticação
    Um servidor local que executa entrada do cliente sem autenticação é uma vulnerabilidade de LCE (Local Code Execution) e,
    quando isso pode ser acessado por requisições do navegador, se amplia para RCE (Remote Code Execution)

  • É chocante colocarem em uma ferramenta CLI um endpoint HTTP com RCE sem autenticação e ainda adicionarem um bypass de CORS em cima disso

    • Talvez os laboratórios de IA precisem parar de treinar modelos com código de tutorial
    • Com o servidor aberto desse jeito, é até surpreendente que a política de CORS não fosse “*”
    • Também houve reações dizendo que isso parece “código feito só no vibe”
  • O problema é o cronograma de divulgação da vulnerabilidade
    Foi relatado em 2025-11-17, mas não houve resposta apesar de várias tentativas de contato

    • Agora parece que os desenvolvedores estão tentando lidar com isso de forma séria
      Veja o comentário na issue do GitHub
    • Também houve uma reação em tom de piada: “hoje em dia todo mundo está fazendo vibe coding, então problema de segurança é bad vibes”
  • Mesmo que o servidor venha desativado por padrão, continua sendo grave quando é ativado
    Qualquer página web no localhost consegue executar código, e também é possível executar processos locais sem autenticação
    Não há sequer um indicador informando ao usuário se o servidor está em execução
    Aplicativos TUI normalmente são confiáveis justamente porque não fazem esse tipo de coisa, e este caso prejudica seriamente essa confiança

    • Também houve quem perguntasse por que justamente um aplicativo TUI seria o problema
    • Como alternativa, houve quem achasse o Droid da Factory uma boa opção
  • É surpreendente que o OpenCode receba apoio da YC (Y Combinator)
    Eu esperava que a YC incentivasse uma cultura de segurança melhor

    • Também houve uma reação cínica de que, no fim, para a YC o que importa é dinheiro
    • Houve um caso anterior em que a Flock, saída da YC, hardcodou a senha 53 vezes
      Veja este comentário sobre isso
    • Além disso, é irônico que a OpenCode também faça produto de provedor de autenticação
  • Achei que o OpenCode fosse um projeto voluntário, mas descobri que na verdade era um projeto empresarial apoiado por grandes investidores

    • Além do repositório oficial no GitHub, havia um projeto concorrente feito pela equipe da charm.sh
    • Provavelmente estavam pensando em projetos como crush, roocode e kilo. Eles ainda não têm grandes patrocinadores
  • Parei de usar porque continuavam adicionando funcionalidades e negligenciando a manutenção central
    O objetivo era usar vários modelos ao mesmo tempo, mas o compartilhamento de contexto é ineficiente, então a utilidade prática acaba sendo baixa
    Agora estou usando Claude Code e Codex em paralelo
    Ainda assim, continua existindo uma grande necessidade de uma plataforma aberta que integre vários modelos

    • Recomendo a combinação de ampcode(link) e Crush(link) + z.ai GLM
      O ampcode permite criar scripts simples de graça, e Crush+GLM segue bem o planejamento do Claude ou do Codex
    • Também houve a opinião de que é mais difícil manter a disciplina de revisão e controle de qualidade do que sair adicionando novas funções
  • No começo eu gostava do Aider, mas ele quase não recebe manutenção, então eu enfrentava problemas com frequência
    Eu estava prestes a instalar o OpenCode, mas depois deste caso fiquei hesitante
    É surpreendente como há tão poucos assistentes LLM CLI open source não dependentes de um modelo específico