Falha na OpenCode pode ter exposto chaves de API de serviços externos
A OpenCode comunicou que um invasor conseguiu acessar um sistema legado da empresa na noite de 16 de outubro. Com isso, chaves de API de provedores externos armazenadas por usuários no Console podem ter ficado expostas. A companhia estima que o incidente possa afetar 1,4% das pessoas que utilizam esse recurso.
O sistema acessado já estava sendo desativado, mas a OpenCode não divulgou como ocorreu a invasão, por quanto tempo o acesso permaneceu ativo ou quantas credenciais estavam armazenadas no ambiente. A empresa também não confirmou que as chaves tenham sido copiadas ou utilizadas por terceiros. Portanto, a possibilidade de exposição não significa, por si só, que houve uso indevido em todos os casos.
A situação se aplica às chaves inseridas no Console por usuários que conectaram provedores externos. Segundo o cofundador da OpenCode, Dax Raad, o problema está restrito ao Console e não representa uma falha no próprio OpenCode. Credenciais adicionadas aos aplicativos de linha de comando e de desktop ficam guardadas localmente na máquina do usuário e não fazem parte do conjunto mencionado no comunicado.
Em 17 de outubro, a empresa enviou mensagens por e-mail às pessoas potencialmente afetadas. A OpenCode afirmou que quem não recebeu essa comunicação não está entre os usuários atingidos. Em uma publicação na rede X, também informou que estava trabalhando com Anthropic, OpenAI e Google enquanto investigava o caso.
A empresa relacionou o incidente a um ataque de destilação em larga escala, mas não explicou de que maneira esse tipo de atividade teria relação com o acesso ao sistema legado. Também não identificou quem seria responsável pela invasão. Até o momento, não foram apresentados detalhes técnicos que comprovem uma ligação entre os dois acontecimentos.
A orientação mais importante para quem pode ter sido afetado é revogar a chave antiga diretamente no painel do provedor correspondente e criar uma nova. Apagar ou remover a credencial do Console não invalida a chave no serviço externo. Por isso, a substituição precisa ser feita no ambiente da Anthropic, da OpenAI, do Google ou de qualquer outro provedor conectado.
Depois da troca, é necessário atualizar cada aplicação, script ou integração que utilizava a credencial anterior. Se a chave antiga continuar configurada em algum serviço, a aplicação poderá deixar de funcionar. Já manter uma credencial potencialmente exposta ativa representa um risco desnecessário, mesmo que ainda não haja confirmação de uso por terceiros.
Também é recomendável revisar o histórico de consumo e as cobranças nos painéis dos provedores, considerando especialmente as atividades registradas desde 16 de outubro. Picos inesperados de uso, solicitações que não correspondam ao trabalho realizado ou custos fora do padrão podem indicar que uma credencial foi utilizada sem autorização. Caso apareça algo suspeito, o usuário deve abrir um chamado com o provedor e guardar os registros disponíveis.
Para reduzir impactos futuros, organizações que usam chaves de API devem acompanhar o consumo com limites e alertas, evitar manter credenciais sem necessidade e substituir periodicamente as que dão acesso a serviços importantes. Também é prudente utilizar permissões mínimas: uma chave não precisa ter acesso a funções ou recursos que a aplicação não utiliza.
O episódio reforça a diferença entre excluir uma credencial de uma ferramenta e invalidá-la no serviço que a emitiu. A primeira ação pode apenas remover a chave de uma configuração; a segunda impede que ela continue autorizando chamadas à API. Em caso de possível exposição, a revogação no painel do provedor é a medida que efetivamente encerra o acesso concedido por aquela credencial.