O que aconteceu: Forgejo 16.0.4 e o problema em templates

O Forgejo publicou as notas de versão da linha 16.0.4 com correções de segurança importantes. A mais grave descrita no documento impede que a expansão de variáveis de um repositório modelo interfira na inicialização do novo repositório Git. O fluxo legítimo começa com a clonagem do modelo, remove a pasta de metadados Git, expande variáveis em arquivos permitidos e, no fim, inicializa um novo repositório para o usuário. A falha permitia que a expansão fosse abusada para criar novamente uma pasta .git antes da inicialização. Um modelo malicioso poderia então fazer o Git adotar esse conteúdo durante o processo e abrir caminho para leitura de dados arbitrários e execução de processos no host do Forgejo. A própria nota classifica a correção como crítica. Ela não informa um identificador CVE nem uma pontuação CVSS para esse problema específico, portanto não há motivo para inventar esses dados. A mesma versão também documenta uma correção no controle de autorização de APIs e outra para o acesso a anexos de releases em rascunho.

O ponto central para administradores é que o risco nasce na fronteira entre conteúdo controlado por usuários e uma operação executada pelo servidor. Templates parecem arquivos comuns, mas participam de uma automação que manipula um repositório e chama o Git no host. Essa combinação exige atualização, revisão de permissões e observabilidade do processo de criação de repositórios.

Como funciona o ataque

Em uma operação normal, uma instância Forgejo recebe um repositório modelo, clona seu conteúdo em uma área de trabalho e remove a pasta .git do clone. Depois, aplica a expansão de variáveis nos arquivos declarados por .forgejo/template. Somente quando essa etapa termina o servidor deve preparar a nova estrutura Git. O problema corrigido em 16.0.4 era a possibilidade de a expansão variável produzir uma nova pasta .git dentro da área que seria inicializada. Na etapa seguinte, o Git poderia reconhecer essa pasta como parte da estrutura do repositório e incorporá-la ao processo de inicialização.

Isso muda a natureza do conteúdo processado. Em vez de ser apenas um texto substituído em um arquivo, uma entrada de template passa a influenciar a estrutura de controle usada pelo Git. Um atacante que conseguisse fornecer ou controlar um modelo malicioso poderia tentar fazer o servidor ler arquivos disponíveis para a conta de serviço ou executar processos no host. O resultado exato dependeria das permissões do processo Forgejo, do sistema operacional, do isolamento da instalação e das regras de saída da rede. A correção remove qualquer pasta .git existente após a expansão e antes da inicialização, fechando a interferência descrita na nota oficial.

Há ainda dois fluxos de segurança relacionados na mesma versão. Em APIs que verificam se um mantenedor pode editar uma branch de outro proprietário por causa de um pull request com edição permitida, o controle especializado não considerava todas as restrições da autenticação da API. Um token limitado por repositório poderia, em determinadas condições, ultrapassar sua permissão. Também havia rotas de anexos que permitiam consultar metadados e conteúdo de releases em rascunho sem aplicar a mesma verificação feita em outras rotas.

Quem foi afetado

O primeiro risco interessa principalmente a instalações que permitem que usuários não totalmente confiáveis criem repositórios a partir de templates. Isso inclui servidores multiusuário, forjas compartilhadas por equipes grandes, ambientes que aceitam contribuições externas e organizações que importam modelos de fontes variadas. Mesmo quando os templates atuais são internos, a atualização continua necessária, porque a segurança depende do comportamento do servidor quando um novo modelo for adicionado no futuro.

A correção de autorização afeta o fluxo de edição de conteúdo por API quando há pull requests com a opção de permitir alterações por mantenedores. O risco não se limita a tokens administrativos. A nota chama atenção para restrições específicas de autenticação, como tokens vinculados a um repositório. Equipes que usam automações, integrações ou tokens de escopo reduzido devem revisar ações realizadas por essas identidades e confirmar que o princípio do menor privilégio continua válido.

O problema dos anexos de releases em rascunho tem outro alcance. Usuários com somente leitura de um repositório, inclusive chamadas não autenticadas em repositórios públicos, poderiam obter metadados e o conteúdo completo de anexos pertencentes a releases que deveriam estar ocultos. O fato de um repositório ser público não torna um rascunho público automaticamente. Por isso, equipes que armazenam builds, documentos internos ou materiais ainda não publicados em anexos devem tratar a exposição como uma possibilidade a investigar.

Como identificar a exploração

As notas de versão não fornecem uma lista de indicadores de comprometimento com hashes, domínios ou nomes de arquivos específicos. A detecção precisa combinar telemetria da aplicação com evidências do host. Comece preservando os logs do Forgejo e identifique criações de repositório feitas a partir de templates, o usuário que iniciou cada operação, o horário, a origem da solicitação e o nome do modelo. Compare essas ações com eventos de processo registrados pelo sistema operacional.

Procure criação inesperada de pastas .git em diretórios temporários usados durante a geração de repositórios. Observe processos filhos do Forgejo que não fazem parte do padrão normal de inicialização, acessos a arquivos fora do diretório de dados, comandos Git mantidos abertos por tempo incomum e conexões de saída iniciadas logo após a criação de um repositório. Esses sinais não provam exploração isoladamente, mas ajudam a formar uma linha do tempo. Não execute uma suposta prova de conceito em produção para confirmar o problema.

Para a falha de autorização, exporte os registros de chamadas à API e filtre tokens com escopo restrito que tenham escrito em branches ou repositórios fora do conjunto esperado. Revise mudanças, commits, criação de branches e permissões alteradas no período de exposição. Para anexos de releases, consulte os logs HTTP em busca de acessos a rotas de download associados a releases em rascunho e compare cada solicitação com a identidade autorizada. Preserve os registros antes de fazer limpeza ou rotação, respeitando a política de retenção da organização.

Como se proteger e mitigar

A medida principal é atualizar a instância para o Forgejo 16.0.4 ou para uma versão posterior que contenha as mesmas correções. Antes da mudança, confirme a versão instalada, faça backup conforme o procedimento do ambiente e teste a atualização em uma instância de homologação. Após o restart, valide criação de repositórios, uso de templates, pull requests, chamadas de API com tokens restritos e visibilidade de releases em rascunho. Registrar a versão e o resultado do teste facilita auditorias futuras.

Até a atualização, reduza a superfície de risco. Restrinja quem pode criar e publicar templates, remova modelos de procedência desconhecida e prefira uma lista interna revisada. Se o produto permitir separar templates confiáveis de conteúdo recebido de terceiros, aplique essa separação. Execute o Forgejo com uma conta de serviço sem privilégios administrativos, mantenha arquivos sensíveis fora do alcance dessa conta quando possível e limite conexões de saída do host. Isolamento de rede não substitui o patch, mas reduz o impacto caso uma execução inesperada ocorra.

Se houver indícios de exploração, coloque a instância em contenção conforme o plano de resposta, preserve logs e imagens do host e avalie a troca dos tokens usados por automações. Revogue tokens suspeitos, crie novos com o menor escopo necessário e verifique alterações recentes em repositórios e branches. Não apague evidências antes de concluir a coleta. Para anexos em rascunho, identifique quais materiais poderiam conter informação sensível e aplique a política de incidente da organização.

Comparação com outros casos

Este caso não deve ser reduzido a um simples problema de arquivo exposto. A falha combina expansão de conteúdo, manipulação de uma estrutura Git e inicialização de um repositório no lado do servidor. É mais útil compará-la a uma falha de cadeia de suprimentos ou de template server-side: o conteúdo fornecido por alguém atravessa uma fronteira de confiança e passa a influenciar uma automação privilegiada.

A segunda correção, relacionada à autorização de APIs, lembra um problema de confused deputy. Um componente especializado reconhecia uma condição válida para permitir edição por mantenedores, mas não repassava todas as restrições do mecanismo de autenticação. A lição é revisar o conjunto completo de permissões em cada caminho, e não apenas a decisão local de que uma ação parece autorizada.

O terceiro item tem relação com uma classe diferente de falhas: exposição de recursos que deveriam permanecer ocultos por estado. As notas do Forgejo relacionam o acesso indevido a anexos de releases em rascunho a uma correção upstream descrita pelos identificadores CVE-2026-27660 e GHSA-q9pg-jj6x-j9p6. Isso não transforma automaticamente o problema de templates em um desses identificadores. São superfícies distintas, reunidas na mesma atualização, e devem ser verificadas separadamente no inventário de risco.

Análise técnica

A referência técnica principal é o PR 14301 do Forgejo, associado às correções de segurança publicadas nas notas da versão 16.0.4. No fluxo vulnerável, o servidor clona o modelo, remove a pasta .git, executa expansão variável em arquivos listados por .forgejo/template e depois inicia o novo repositório. O ajuste documentado acrescenta uma garantia de limpeza após a expansão, removendo uma pasta .git que tenha surgido antes de chamar a inicialização Git.

Esse detalhe de ordenação é essencial. Remover .git somente antes da expansão não basta, porque a etapa posterior pode alterar a árvore de arquivos. A validação deve ocorrer imediatamente antes da operação que cria o novo repositório e deve considerar o diretório efetivamente usado pelo processo. A correção também reforça o controle de autorização para que verificações de edição em pull requests considerem as restrições específicas da autenticação da API. Em paralelo, rotas de anexos passam a verificar o estado de rascunho da release antes de devolver metadados ou conteúdo.

O release note oficial não fornece um CVSS para a RCE descrita. A avaliação local deve considerar exposição de templates, capacidade de criação de repositórios, identidade do processo Forgejo, permissões no sistema de arquivos, isolamento do serviço, conectividade de saída e presença de dados sensíveis no host. Uma classificação interna pode ser alta ou crítica conforme esses fatores, mas ela não deve ser apresentada como pontuação oficial. O importante é relacionar a versão instalada com a correção e registrar a decisão de atualização.

Impacto e consequências

Se explorada, a falha de templates pode afetar confidencialidade, integridade e disponibilidade. A confidencialidade pode ser comprometida se o processo conseguir ler configurações, chaves ou dados de outros componentes acessíveis à conta de serviço. A integridade pode ser afetada por alterações em repositórios, arquivos ou processos. A disponibilidade pode sofrer com processos inesperados, consumo de recursos ou alterações que impeçam o serviço de iniciar normalmente.

O impacto real não é igual em todas as instalações. Um Forgejo executado com usuário dedicado, diretórios sensíveis protegidos, rede de saída limitada e isolamento adequado oferece menos alcance do que um serviço com permissões amplas. Da mesma forma, uma instância que aceita templates externos tem exposição diferente de uma instância onde somente administradores fornecem modelos. Essas diferenças reduzem ou ampliam o impacto, mas não eliminam a necessidade de corrigir a versão.

O bypass de autorização pode permitir mudanças que um token restrito não deveria fazer, criando risco de código alterado, branch contaminada ou pipeline acionado indevidamente. A exposição de anexos em rascunho pode revelar artefatos, documentos ou builds antes da publicação. Em ambos os casos, a consequência pode ser operacional e reputacional mesmo sem evidência de execução de código. A resposta deve ser baseada em evidências: não declare comprometimento sem confirmar os registros, mas também não descarte sinais apenas porque a aplicação continuou respondendo.

Dicas práticas e boas práticas

Use o seguinte checklist para reduzir a exposição de uma instância Forgejo:

  1. Identifique a versão instalada e confirme se a correção da linha 16.0.4 está presente.
  2. Faça backup e atualize primeiro em homologação com um conjunto representativo de templates.
  3. Liste todos os repositórios modelo e registre proprietário, origem e última revisão.
  4. Restrinja criação e publicação de templates a pessoas e grupos que realmente precisam dessa função.
  5. Execute o serviço com uma identidade dedicada e sem privilégios administrativos no sistema operacional.
  6. Separe dados do Forgejo de arquivos de configuração, chaves e backups de outros serviços.
  7. Limite a saída de rede do host e monitore processos filhos iniciados pelo serviço.
  8. Revise tokens de API, seus escopos e os repositórios alcançados por cada automação.
  9. Teste que releases em rascunho e seus anexos exigem a autorização correta em todas as rotas.
  10. Centralize logs de aplicação, API, sistema de arquivos, processos e rede para criar uma linha do tempo.
  11. Defina rotação de tokens e preservação de evidências no plano de resposta a incidentes.
  12. Documente a versão, o backup, o resultado dos testes e a data da atualização.

Também vale revisar o processo de aprovação de templates. Um revisor deve observar não apenas o texto expandido, mas a forma como a automação manipula diretórios, permissões e ferramentas do sistema. Em ambientes com muitos contribuidores, trate templates como código executado indiretamente e aplique revisão, rastreabilidade e separação de funções.

Conclusão: o que fazer agora

Atualize o Forgejo para 16.0.4 ou posterior, confirme que o serviço voltou com a versão esperada e repita os testes dos fluxos de template, API e releases em rascunho. A correção de segurança só é parte do trabalho: inventarie templates, tokens, permissões do serviço e logs de criação de repositórios. Se a instância processa conteúdo de terceiros, considere essa capacidade uma fronteira de segurança e não apenas uma conveniência de produtividade.

Depois da atualização, procure sinais históricos de pastas .git inesperadas, processos anômalos, alterações fora do escopo de tokens restritos e downloads de anexos ocultos. Se encontrar evidências, preserve os dados, contenha o serviço segundo o plano de resposta e faça a rotação de credenciais afetadas. Não atribua um CVE ou uma pontuação CVSS que não apareça na fonte oficial. O procedimento mais seguro é registrar a versão corrigida, a referência técnica do Forgejo e as evidências que sustentam a decisão.

Para acompanhar o tema, consulte as notas oficiais da versão 16.0.4 e o PR 14301. Manter o servidor atualizado, reduzir privilégios e observar os caminhos que transformam conteúdo em operações de sistema são medidas que protegem não apenas o Forgejo, mas toda a cadeia de desenvolvimento conectada a ele.