O Git auto-alojado provou o seu preço de soberania

Onze segundos foram suficientes

A CVE-2026-60004 é uma falha de injeção de código no Gitea, a alternativa auto-alojada ao GitHub usada por equipas que preferem manter o seu código-fonte em servidores próprios em vez de numa plataforma norte-americana. O investigador Shai Rod, conhecido como NightRang3r, descobriu que um atacante com apenas acesso de escrita comum a um repositório podia enviar um patch malicioso para o ponto de acesso da API diffpatch do Gitea, plantar um gancho Git executável e executar comandos de shell arbitrários como a conta de serviço do Gitea. Com o registo aberto ativado por predefinição no Gitea, esse acesso não exige mais do que um registo normal como utilizador.

Num ataque documentado, um fornecedor de alojamento assinalou atividade invulgar numa instância desatualizada do Gitea. Um atacante tinha registado uma conta, criado um repositório, desencadeado a cadeia de exploração, escrito uma prova de conceito num ramo Git, descarregado um carregador de shell e instalado um dropper de mineração de criptomoedas que consumiu 70 por cento da capacidade de processamento do servidor, tudo em cerca de onze segundos. Não foi instalado qualquer mecanismo de persistência; a carga desapareceu no reinício seguinte do contentor, mas a janela de exposição só se fechou porque alguém estava atento.

A cronologia que devia preocupar qualquer auto-alojador

O que transforma este caso num aviso e não numa notícia de patch de rotina é quão pouco tempo separou a disponibilidade de uma correção da exploração real em grande escala.

Passou-se menos de um mês entre uma correção pública e a exploração confirmada, e as instâncias que continuavam a ser atacadas eram precisamente as que não tinham aplicado um patch disponível publicamente há semanas. A janela de três dias que a CISA deu às agências federais não é uma formalidade burocrática; reflete a rapidez com que uma falha conhecida e corrigida se torna uma arma ativa assim que os atacantes reparam que ainda existem alvos por corrigir.

Porque é que a Europa escolheu este tipo de ferramentas

O Gitea não se tornou popular nas organizações europeias por acaso. Sob a pressão do NIS2, das regras de residência de dados e de um impulso mais amplo para reduzir a dependência de plataformas na nuvem de propriedade norte-americana, muitas empresas europeias de média dimensão e organismos públicos escolheram o Git auto-alojado precisamente para que o seu código-fonte, credenciais e pipelines de integração contínua nunca tocassem no GitHub, na Microsoft ou noutro serviço controlado pelos EUA. Trata-se de uma decisão de soberania legítima e muitas vezes bem fundamentada, e nada nesta vulnerabilidade muda a lógica subjacente de querer o próprio código numa infraestrutura que se controla.

O que muda é o preço associado a essa decisão. Uma plataforma gerida absorve a monitorização de patches, o reforço das configurações predefinidas e a resposta a incidentes como parte daquilo que um cliente paga. Uma instância auto-alojada transfere tudo isso para a equipa interna que a configurou, muitas vezes anos antes, por vezes sem que reste alguém que se lembre se o registo aberto alguma vez foi desativado.

A conta da soberania vence nas janelas de patch

A solução prática aqui não é abandonar o auto-alojamento. A própria orientação do Gitea para esta falha é concreta e imediata: desativar o registo aberto definindo DISABLE_REGISTRATION como true, exigir confirmação por email para qualquer criação de conta que permaneça aberta, desligar o registo por OpenID se não estiver em uso ativo, e exigir autenticação antes de permitir que alguém navegue pelas páginas ou chame a API. Qualquer organização que utilize o Gitea, ou uma plataforma auto-alojada comparável, deve rever estas quatro definições hoje mesmo, não depois da próxima CVE.

A lição mais ampla diz respeito à forma como as decisões de soberania são orçamentadas. Escolher o auto-alojamento por motivos de residência de dados ou independência é uma decisão real e defensável, mas só está completa se vier acompanhada do compromisso com o trabalho contínuo de segurança operacional que um fornecedor gerido teria de outro modo assumido automaticamente. Um patch que ficou por aplicar durante um mês numa instância exposta à internet com registo aberto não é uma falha da decisão de soberania; é uma falha em calcular o que essa decisão custa realmente para operar em segurança.

Leia a seguir: NCSC exige paragem de emergência para agentes IA  |  Se usa Zimbra, 21 de agosto mudou o seu risco