O que a OpenCode disse
A OpenCode, o agente de código aberto para terminal criado pela equipa por trás da SST, divulgou uma falha numa publicação no X a 17 de outubro. O texto tem quatro frases e é, para já, o único relato público da empresa.
«Tivemos uma falha de segurança ontem à noite relacionada com um ataque de destilação em larga escala que afetou 1,4% dos utilizadores da OpenCode Console», lê-se. «Notificámo-los a todos esta manhã por email. Se não recebeu um email, não foi afetado; foi um subconjunto de utilizadores que tinham fornecedores externos ligados. O incidente está em curso, por isso não podemos partilhar mais detalhes neste momento, mas estamos a trabalhar com a Anthropic, a OpenAI e a Google para corrigir.»
Essa última frase descreve a forma do problema. A OpenCode Console permite ao utilizador ligar as suas próprias contas em fornecedores de modelos, o que significa que a plataforma guarda credenciais pertencentes ao serviço de outra empresa. A falha não é do modelo da OpenCode; é das chaves que os seus utilizadores apontaram aos modelos de terceiros.
Porque «ataque de destilação» é o nome certo
A expressão descreve o que vale uma chave de fornecedor roubada. Não é sobretudo um caminho para dados: é a capacidade de enviar um volume muito grande de consultas a um modelo de fronteira na conta de outra pessoa, que é como se paga uma destilação contra um modelo comercial. O primeiro sinal para a vítima é uma fatura.
Numa análise publicada no mesmo dia, a empresa de segurança Cyera disse que o email de notificação da OpenCode atribuía a intrusão a um sistema de consola antigo que a empresa estava a desativar, e que as credenciais expostas eram chaves de fornecedores ligadas nos espaços de trabalho afetados. As recomendações da Cyera referem também a OpenRouter, a par dos três fornecedores que a OpenCode nomeou.
O que não foi dito
Faltam quatro coisas na divulgação, e todas importam a quem tente calcular a sua exposição.
Primeiro, o denominador. 1,4% dos utilizadores da Console é uma proporção, não uma contagem, e a OpenCode não publicou o total. Segundo, o ponto de entrada: a empresa disse qual o sistema envolvido, mas não como o atacante lá chegou nem como as chaves estavam guardadas. Terceiro, se alguma chave exposta foi efetivamente usada: a OpenCode não confirmou uso indevido, e o incidente foi descrito como em curso. Quarto, a atribuição: ninguém apontou publicamente o responsável.
O que foi pedido aos utilizadores afetados
O conselho é o procedimento habitual de rotação de credenciais, com um pormenor próprio deste tipo de incidente. Revogar e reemitir todas as chaves de fornecedor ligadas num espaço de trabalho afetado, através do painel de cada fornecedor e não da OpenCode ou de uma ligação num email. Atualizar as ferramentas e os processos que usam essas chaves e confirmar que as antigas deixaram de funcionar. Repor a palavra-passe da conta OpenCode e gerar de novo quaisquer chaves API da OpenCode Console.
O pormenor é a revisão da faturação. A recomendação da Cyera é verificar o uso e a faturação do fornecedor a partir de 16 de outubro à procura de picos, modelos desconhecidos ou atividade a horas estranhas — porque num ataque de destilação o dano aparece como consumo e não como um registo em falta. Limites rígidos de despesa e chaves delimitadas por projeto são os controlos que o travam.
As chaves usadas diretamente na aplicação local da OpenCode ficam guardadas na máquina do utilizador e não na Console, o que as deixa fora deste incidente.
O que observar
A OpenCode prometeu mais detalhes quando o incidente fechar. As partes úteis desse relatório são as duas que reteve: o caminho de acesso e se as chaves foram usadas. A segunda pergunta é a que dirá ao resto do setor se uma ferramenta de desenvolvimento que guarda credenciais de fornecedores é um alvo fácil que vale a pena atacar em escala, ou se isto foi oportunista.
