O fornecedor avisa que um repositório ficou público. Alguém encontra um arquivo de configuração com acesso ao banco de dados. O primeiro impulso é apagar tudo e trocar a senha do GitHub. Se o código-fonte vazou, essas duas ações podem deixar acessos expostos funcionando e ainda dificultar a investigação.
O trabalho começa por descobrir o que foi exposto, interromper os acessos indevidos e manter evidências. Ter uma cópia do código não equivale automaticamente a controlar o sistema, mas uma credencial válida dentro dessa cópia pode permitir acesso a outro serviço.
Referências verificadas em 22 de outubro de 2026. Este é um guia de resposta a exposição de código e credenciais. Ele não descreve um caso confirmado de roubo de código de cliente da Coffe&Code.
Código-fonte vazou: o que isso permite descobrir
Código-fonte descreve como o software funciona. Dependendo do conteúdo, uma cópia pode revelar regras comerciais, integrações e a estrutura de permissões. O impacto precisa ser avaliado mesmo quando não existe senha no repositório.
Já uma credencial é um meio de acesso: senha de banco, chave de API, token de publicação ou chave privada, por exemplo. O risco depende de quais operações ela autoriza e de onde pode ser usada.
Considere um exemplo hipotético. Uma loja tem quatro credenciais de integração: pagamento, envio de e-mail, frete e banco de dados. O repositório exposto contém somente a chave de envio de e-mail. Não há base para afirmar que os cartões dos clientes foram roubados. Há motivo para invalidar a chave exposta e investigar seu uso, inclusive o envio de mensagens em nome da empresa.
Essa distinção define onde agir primeiro. Colocar o repositório de volta no modo privado reduz a exposição dali em diante, mas não recolhe cópias já obtidas. O GitHub explica os limites da remoção de dados de um repositório: clones e outras referências exigem cuidados adicionais, e credenciais expostas devem ser revogadas ou substituídas antes de concentrar o esforço na limpeza do histórico.
O que o caso PHP2Shell tem a ver com isso
Nos avisos oficiais do PHP2Shell, o problema é uma vulnerabilidade que pode permitir execução de código no servidor. Isso não demonstra que um repositório privado específico tenha sido copiado.
Se a sua dúvida começou com essa notícia e não há evidência de exposição de arquivos, comece pelo guia sobre a falha no PHP e a cobrança à hospedagem. A resposta abaixo se aplica quando há exposição identificada ou indícios que precisam ser investigados.
As primeiras ações quando aparece um arquivo exposto
Acione o responsável técnico por um canal já conhecido. Nomeie uma pessoa para coordenar as decisões e anote quando a empresa tomou conhecimento. A contenção não deve esperar a conclusão de um relatório completo.
Peça à equipe que trabalhe nestas frentes:
- Restringir a exposição: corrigir a publicação indevida ou bloquear o acesso comprometido.
- Invalidar acessos expostos: revogar as credenciais envolvidas e preparar a substituição nos serviços dependentes.
- Preservar evidências: guardar registros da exposição e das ações realizadas em local restrito.
- Definir o alcance: identificar arquivos, períodos e ambientes envolvidos.
Essas atividades podem ocorrer em paralelo. Não mantenha uma chave vazada ativa para terminar de documentar o caso. Também não destrua a única cópia dos registros porque o problema parece resolvido.
Para a coordenação, um registro inicial já ajuda: qual repositório ou servidor foi afetado, quem detectou o problema, quais contas podem conter a exposição e quem está executando cada ação. Os valores das senhas não precisam aparecer nesse registro.
Por que apagar o arquivo não cancela a senha
Excluir um arquivo altera o conteúdo atual do projeto. Isso não envia ao banco de dados ou ao provedor de pagamento uma ordem para invalidar a credencial que estava nele. Se alguém a copiou, pode tentar usá-la enquanto continuar válida.
A OWASP orienta revogar as chaves expostas e organizar sua substituição. A implementação depende do serviço afetado. Uma chave usada por vários sistemas exige mapear os consumidores para que a nova credencial seja instalada nos lugares certos.
No exemplo da loja, o responsável revoga a chave de envio de e-mail e configura outra na aplicação. Depois, valida um envio autorizado e confere a invalidação da anterior no provedor. Se uma rotina de cobrança também usava a chave antiga, ela entra na atualização. Não adianta encerrar o incidente com o site funcionando e descobrir depois que os avisos de pagamento pararam.
Trocar apenas a senha da conta administrativa pode não cancelar todos os tokens, sessões ou chaves de integração associados. Peça a conferência desses acessos no serviço correspondente. Se a conta que administra a infraestrutura estiver comprometida, a equipe também precisa recuperar seu controle antes de confiar nela para distribuir novas credenciais.
O que pedir para a investigação verificar
Não aceite “o GitHub vazou” como diagnóstico completo. A origem pode estar na visibilidade de um repositório, no acesso de um colaborador ou na publicação de um arquivo no servidor. Cada hipótese pede evidências diferentes.
Peça respostas documentadas para estas perguntas:
- Qual material ficou acessível e desde quando?
- A exposição ocorreu no repositório, em um pacote publicado ou no servidor?
- Quais credenciais estavam presentes, inclusive no histórico?
- Que ambientes essas credenciais alcançavam?
- Houve mudança não autorizada no código ou na configuração de publicação?
- Existem registros de uso indevido dos serviços envolvidos?
O log de auditoria de uma organização no GitHub ajuda a examinar ações registradas e seus responsáveis. Ele não deve ser tratado como inventário completo de tudo que alguém pode ter feito com uma cópia local do código.
Uma boa resposta explicita o limite das evidências: “há confirmação de exposição deste arquivo; a análise dos registros do banco continua pendente”. Isso permite decidir com o que já se sabe, sem transformar hipótese em certeza.
Como limpar o repositório sem perder o controle da entrega
Depois de invalidar as credenciais, a equipe avalia em quais versões e cópias do projeto o material sensível permanece. Apagar o arquivo na versão atual não o remove das anteriores.
Alterar esse histórico exige coordenação. Pode afetar entregas em andamento e permitir que uma cópia antiga reintroduza o conteúdo removido. Não peça um comando de limpeza indiscriminada em todos os computadores. Peça um plano com os repositórios afetados, os colaboradores envolvidos e uma forma de verificar o resultado.
Se dados pessoais ou outro conteúdo sensível permanecerem acessíveis no provedor, consulte o procedimento de suporte aplicável. Remover uma publicação é diferente de conseguir apagar todas as cópias que terceiros já fizeram.
O objetivo operacional é retomar o desenvolvimento sem credenciais válidas no histórico e sem republicar o material que acabou de ser removido. Preserve separadamente o que for necessário à investigação, com acesso limitado.
E se o código foi copiado do servidor em produção?
Nesse cenário, a investigação não termina no repositório. Se alguém obteve execução no servidor, a equipe precisa avaliar também arquivos modificados, novas contas e acessos a serviços conectados, conforme as permissões disponíveis naquele ambiente.
Não assuma que restaurar a versão anterior do site elimina todos os acessos indevidos. A recuperação precisa considerar a origem da invasão, a confiabilidade da cópia restaurada e as credenciais que estavam disponíveis no servidor. Quando necessário, o responsável técnico deve preparar um ambiente confiável para a retomada.
Peça um critério de liberação que cubra tanto a operação quanto a segurança: o fluxo de pedidos foi validado, os acessos envolvidos foram tratados e os registros relevantes foram preservados. A aparência normal da página inicial não responde a essas perguntas.
Vazamento de código exige avisar todos os clientes?
A avaliação depende do que aconteceu. A ANPD esclarece que nem todo incidente envolve dados pessoais ou exige comunicação. A obrigação considera a ocorrência confirmada, o envolvimento de dados pessoais sujeitos à LGPD e a possibilidade de risco ou dano relevante aos titulares.
Envolva prontamente o responsável pela privacidade e a assessoria jurídica para avaliar as obrigações e os prazos aplicáveis. Não espere concluir toda a investigação para iniciar essa avaliação. Registre o fundamento das decisões e atualize a análise quando surgirem evidências.
Na comunicação operacional, diferencie o que foi confirmado do que continua sendo apurado. Não declare que dados de clientes estão seguros somente porque ninguém encontrou uma planilha dentro do repositório.
O que mudar na próxima entrega de software
Depois da contenção, inclua uma verificação de segredos no processo de desenvolvimento. O secret scanning do GitHub procura padrões de credenciais no histórico e em outras superfícies do repositório. Verifique a disponibilidade para o seu plano e tipo de projeto. Uma ferramenta de detecção ajuda, mas não garante ausência de todo segredo possível.
Combine também quem administra os acessos e como eles serão revogados quando um fornecedor sair. Credenciais de teste não devem servir para operar a produção. A empresa precisa conseguir localizar os responsáveis sem depender de uma senha compartilhada em conversa antiga.
O guia sobre contratar desenvolvedor sem perder o controle do código trata da organização desses ativos desde a contratação. Aqui, a cobrança seguinte é conseguir demonstrar quais acessos foram encerrados e quais controles vão detectar uma nova exposição.
Se sua empresa não consegue relacionar repositórios e credenciais aos sistemas que eles atendem, leve esse problema para uma avaliação de suporte estratégico em TI. O trabalho precisa começar por esse inventário, para que o próximo alerta tenha um responsável capaz de agir.