Falha na OpenCode pode ter exposto chaves de API de outros provedores
A OpenCode informou que um invasor conseguiu acessar um sistema legado na noite de 16 de outubro. Nesse ambiente estavam armazenadas chaves de API de serviços externos que alguns usuários haviam cadastrado no Console da empresa. A companhia classificou a exposição como possível, mas não confirmou que as credenciais tenham sido copiadas ou utilizadas.
O incidente atingiria cerca de 1,4% dos usuários do Console. A OpenCode não divulgou quantas chaves estavam guardadas no sistema, por quanto tempo o acesso indevido permaneceu ativo ou qual vulnerabilidade permitiu a invasão. Segundo a empresa, o sistema comprometido já estava sendo desativado.
A situação também não significa que todos os usuários da OpenCode estejam em risco. O alcance descrito se restringe às pessoas que adicionaram credenciais de provedores externos ao Console. De acordo com o cofundador Dax Raad, o problema envolve esse serviço, e não o OpenCode como um todo. As chaves configuradas nos aplicativos de linha de comando e de desktop ficam armazenadas localmente no computador do usuário.
Em 17 de outubro, a empresa enviou um aviso por e-mail às pessoas que considera afetadas. A OpenCode afirmou que quem não recebeu a mensagem não foi atingido pelo incidente. Em uma publicação na rede X, declarou estar trabalhando com Anthropic, OpenAI e Google enquanto apurava o caso.
A empresa relacionou o episódio a um ataque de destilação em larga escala, mas não explicou de que forma esse tipo de atividade estaria ligado ao acesso ao sistema legado. Também não identificou um responsável pelo ataque. Até o momento, não foram apresentados detalhes técnicos que comprovem uma conexão entre os dois acontecimentos.
Embora a possibilidade de exposição não seja o mesmo que a confirmação de uso indevido, a recomendação é tratar as credenciais cadastradas no Console como potencialmente comprometidas. A OpenCode orientou os usuários afetados a revogar as chaves nos painéis dos respectivos provedores e criar novas credenciais. Apagar uma chave do Console, por si só, não a invalida: ela continua ativa até que seja revogada junto à empresa que a emitiu.
Depois de gerar novas chaves, é importante substituir as antigas em todos os sistemas que dependiam delas. Isso pode incluir aplicações, scripts, ambientes de desenvolvimento e serviços automatizados. Se uma credencial antiga permanecer configurada em algum lugar, a aplicação poderá continuar tentando utilizá-la, causando erros ou dificultando a investigação.
Os usuários também devem revisar o histórico de consumo e as cobranças nas contas dos provedores, dando atenção especial às atividades registradas desde 16 de outubro. Picos inesperados de uso, chamadas a modelos ou serviços que não foram solicitados e custos fora do padrão podem ser sinais de utilização indevida. A ausência de cobranças incomuns, por outro lado, não prova que uma chave não tenha sido acessada.
Ao fazer a substituição, vale evitar o envio das novas credenciais por mensagens ou documentos compartilhados. O ideal é armazená-las em um gerenciador de segredos ou no mecanismo seguro recomendado pelo provedor. Também é prudente limitar as permissões da chave ao que a aplicação realmente precisa e, quando houver essa opção, restringir seu uso por projeto, serviço ou ambiente.
Empresas que usam o Console em equipes devem identificar quais pessoas e sistemas tinham acesso às credenciais afetadas. Além da troca das chaves, convém verificar registros de atividade, atualizar procedimentos internos e comunicar os responsáveis pelos serviços que poderiam ter sido impactados. Essa organização reduz o risco de alguma integração continuar operando com uma credencial antiga.
O episódio reforça que chaves de API funcionam como credenciais de acesso e precisam ser protegidas com o mesmo cuidado dedicado a senhas e tokens. Guardá-las em sistemas centralizados facilita a configuração, mas também pode ampliar o impacto de uma invasão. Para diminuir esse risco, organizações podem adotar permissões mínimas, monitoramento de consumo, rotação periódica de credenciais e alertas para atividade fora do padrão.
A investigação da OpenCode ainda não esclareceu como o invasor alcançou o sistema nem se alguma chave foi efetivamente extraída. Até que essas questões sejam respondidas, usuários que receberam o aviso devem concluir a revogação e a substituição das credenciais, revisar o histórico de uso e confirmar que todas as aplicações passaram a utilizar as novas chaves.