Vulnerabilidade em opções de envio do Git permitia execução remota de código por usuário autenticado com permissão de gravação em repositório.
| Componente | GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud com Data Residency, GitHub Enterprise Cloud com Enterprise Managed Users e GitHub Enterprise Server. |
| Vetor | Usuário autenticado com acesso de envio a um repositório podia acionar a falha por meio de valores manipulados em opções de git push. |
| Impacto | CVE-2026-3854 permitia injeção de comando e execução remota de código no processamento interno do envio, com risco de execução como usuário git e exposição cruzada em backend compartilhado. |
| Prioridade | Aplicar imediatamente as versões corrigidas do GitHub Enterprise Server e revisar telemetria de envios com opções de push anômalas. |
| Versões | Correção disponível no GitHub Enterprise Server 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 ou posteriores. |
| CVSS | CVE-2026-3854 recebeu pontuação CVSS 8.7. |
| Exploração | O contexto informa que não havia evidência de exploração maliciosa conhecida no momento da divulgação. |
CVE-2026-3854 é uma vulnerabilidade de injeção de comando no fluxo de processamento de git push usado por serviços do GitHub. A falha afeta GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud com Data Residency, GitHub Enterprise Cloud com Enterprise Managed Users e GitHub Enterprise Server. O ponto crítico está no tratamento de valores fornecidos pelo usuário em opções de push: esses valores eram incorporados a cabeçalhos internos de serviço sem sanitização suficiente. Como o formato interno usava um caractere delimitador que também podia aparecer no dado controlado pelo usuário, a entrada manipulada conseguia alterar a interpretação dos metadados encaminhados entre serviços.
O cenário de ataque exige uma condição inicial concreta: o operador malicioso precisa estar autenticado e ter permissão de envio para um repositório. Com essa permissão, um único comando git push com opções especialmente construídas podia atingir o caminho vulnerável. O impacto documentado é execução remota de código no ambiente em que o envio era processado. Em demonstração técnica, a cadeia permitiu sobrescrever elementos do ambiente de processamento, contornar proteções de isolamento que normalmente limitam a execução de hooks e executar comandos arbitrários no servidor como usuário git.
A severidade decorre menos da complexidade do comando Git e mais do acoplamento entre dados controlados pelo usuário, protocolo interno e configuração de segurança derivada de cabeçalhos compartilhados. O cabeçalho X-Stat recebia valores associados ao envio e transportava metadados consumidos por outros componentes. Quando um delimitador como ponto e vírgula é aceito dentro de uma entrada não normalizada, serviços posteriores podem interpretar parte do valor como novo campo de controle. Nesse tipo de arquitetura, a validação precisa ocorrer antes da serialização para o protocolo interno, porque cada consumidor pode tomar decisões de segurança com base no mesmo campo.
A falha foi reportada em 4 de março de 2026 e a correção para GitHub.com foi validada e implantada em até duas horas. Para ambientes GitHub Enterprise Server, a correção está disponível nas versões 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 ou posteriores. O contexto também informa que não havia evidência de exploração maliciosa conhecida. Ainda assim, a prioridade operacional é alta, porque a exploração depende de uma permissão comum em ambientes de desenvolvimento e o comando acionador está dentro do fluxo normal de trabalho de usuários com gravação em repositórios.
O fluxo vulnerável começa no envio Git. Durante o git push, o cliente pode transmitir opções de push. Esses valores são entrada controlada pelo usuário e, no caso de CVE-2026-3854, eram propagados para um cabeçalho interno chamado X-Stat. O problema não era apenas aceitar opções de push, mas inserir esses valores em um formato de metadados que separava campos por delimitador. Quando o mesmo delimitador podia aparecer dentro da entrada, uma opção manipulada deixava de ser apenas valor e passava a interferir na estrutura do cabeçalho.
A injeção de campos adicionais permitia alterar metadados usados no processamento do envio. A cadeia descrita envolve múltiplas injeções combinadas para modificar o ambiente no qual o push era tratado. Essa alteração de ambiente era relevante porque proteções de sandbox normalmente restringem a execução de hooks. Ao influenciar campos internos que participavam dessas decisões, o atacante podia chegar a execução de código fora das restrições esperadas, com execução não isolada como usuário git.
No GitHub Enterprise Server, o caminho de hooks personalizados fica ativo por uma marca de modo corporativo configurada como verdadeira. No GitHub.com, essa marca normalmente ficava falsa, o que deixaria o caminho de hooks personalizados inativo. A falha, porém, também permitia injetar essa marca no X-Stat, já que ela era transportada pelo mesmo mecanismo de metadados. Com isso, a diferença operacional entre GitHub.com e GitHub Enterprise Server não eliminava o risco: a configuração que deveria impedir o caminho de execução podia ser influenciada pela própria entrada manipulada.
A cadeia técnica também menciona a inserção de repo_pre_receive_hooks com uma entrada de hook criada para acionar travessia de caminho e execução de comandos arbitrários como usuário git. Esse detalhe delimita o impacto: o objetivo da exploração era chegar a execução de comandos no backend associado ao processamento do repositório, não apenas causar falha, negação de serviço ou erro de validação. Em ambientes com infraestrutura de armazenamento compartilhada, a execução nesse ponto do backend aumentava o alcance potencial do ataque para além do repositório usado como gatilho.
A arquitetura multi-inquilino do GitHub.com amplia o risco porque componentes de backend podem atender múltiplas organizações ou usuários sobre nós de armazenamento compartilhados. No cenário descrito, execução de código no GitHub.com poderia resultar em exposição cruzada entre inquilinos e leitura de repositórios no mesmo nó de armazenamento, independentemente da organização ou usuário proprietário. Essa consequência deve ser tratada como impacto condicionado à exploração bem-sucedida da cadeia, mas é concreta dentro do modelo apresentado: o problema não ficava restrito ao repositório onde o usuário tinha permissão de envio.
A superfície afetada inclui serviços GitHub que processam envios Git e consomem metadados derivados de opções de push. O requisito de autenticação reduz o escopo em relação a uma falha explorável anonimamente, mas não torna o risco baixo. Em organizações grandes, permissões de gravação em repositórios são comuns para desenvolvedores, automações, contas de serviço e integrações de integração contínua. Qualquer identidade com capacidade de executar git push para um repositório dentro de uma instância vulnerável deve ser considerada dentro da superfície de ameaça.
No GitHub Enterprise Server, a exposição depende da versão instalada. As versões corrigidas listadas são 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 ou posteriores. Instâncias em ramos anteriores desses níveis, quando ainda não atualizadas, mantêm o caminho vulnerável. Como o contexto indica que cerca de 88% das instâncias estavam vulneráveis no momento da divulgação pública, a correção não deve ser tratada como manutenção rotineira adiada para janela longa; ela remove um caminho de execução remota de código acionável por fluxo Git legítimo.
Para GitHub.com e GitHub Enterprise Cloud, a correção foi implantada pelo provedor. Ainda assim, organizações que usam esses serviços devem avaliar logs e eventos de auditoria em torno da data de correção, especialmente quando houver repositórios com grande número de colaboradores, automações com permissão ampla ou histórico de pushes incomuns. O fato de não haver evidência de exploração maliciosa conhecida não substitui verificação local, porque a telemetria de cada organização pode revelar abuso de credenciais, tentativas de manipulação de opções de push ou comportamento anômalo de identidades autorizadas.
O componente vulnerável também evidencia um padrão de risco em arquiteturas de múltiplos serviços: protocolos internos não devem confiar que dados já chegaram em formato seguro apenas porque atravessaram uma camada autenticada. A autenticação confirma quem enviou a requisição, mas não torna segura a estrutura do conteúdo. Quando um cabeçalho interno transporta tanto observabilidade quanto parâmetros que influenciam execução, isolamento ou caminho de hooks, qualquer confusão entre dado e delimitador vira superfície de controle.
- Instâncias GitHub Enterprise Server abaixo de
3.14.25,3.15.20,3.16.16,3.17.13,3.18.8,3.19.4ou3.20.0dentro dos ramos suportados. - Repositórios nos quais usuários, automações ou contas de serviço tenham permissão de envio por
git push. - Fluxos que aceitam opções de push e repassam valores para cabeçalhos internos como
X-Stat. - Ambientes multi-inquilino ou com backend compartilhado, nos quais execução no nó de armazenamento pode ampliar o impacto para outros repositórios no mesmo backend.
A investigação deve começar por eventos de envio Git em janelas próximas à correção e à divulgação. O indicador comportamental mais importante é o uso incomum de opções de push por identidades que normalmente não utilizam esse recurso. Como o acionamento da falha ocorre dentro de um comando git push, logs de autenticação e auditoria de repositório podem parecer legítimos no primeiro nível. A diferença está nos parâmetros transmitidos e nos efeitos subsequentes no processamento do backend.
Em GitHub Enterprise Server, administradores devem correlacionar eventos de push com registros de serviços internos responsáveis por hooks, cabeçalhos de metadados e execução no contexto do usuário git. A telemetria útil inclui falhas de parsing de cabeçalho, campos inesperados em X-Stat, alterações de ambiente durante processamento de push, tentativas de resolução de caminhos fora do esperado e execução de hooks que não correspondam à configuração legítima do repositório. Como a cadeia envolve a possibilidade de contornar sandbox, qualquer execução de hook fora das políticas conhecidas precisa ser revisada.
Também é importante procurar sinais indiretos. Se a exploração chegou a execução como usuário git, podem existir artefatos de leitura ou escrita no sistema de arquivos, acesso a configurações internas de serviço, criação temporária de arquivos, erros de permissão, comandos filhos inesperados ou variações anômalas no tempo de processamento do push. O contexto não fornece hashes, endereços IP, domínios ou payloads maliciosos confirmados; portanto, a detecção deve se apoiar em comportamento e consistência operacional, não em IoCs de rede inexistentes.
Em organizações que usam GitHub.com ou GitHub Enterprise Cloud, a capacidade de inspecionar backend é limitada. Nesses casos, a resposta defensiva deve focar eventos de auditoria disponíveis para repositórios, revisão de identidades com permissão de gravação e análise de pushes incomuns. O objetivo é identificar se alguma conta autorizada executou envios com parâmetros atípicos, especialmente quando associados a repositórios sensíveis, contas de serviço ou períodos fora do padrão de atividade da equipe.
- Eventos de
git pushcom opções de push raras, inesperadas ou concentradas em curto período. - Campos anômalos, delimitadores inesperados ou metadados adicionais em registros associados ao cabeçalho
X-Stat. - Execução de hooks incompatível com a configuração conhecida do repositório ou do GitHub Enterprise Server.
- Processos filhos, leituras de configuração ou escrita de arquivos atribuídos ao usuário
gitdurante o processamento de push. - Atividade de contas de serviço ou usuários com permissão de envio em repositórios sensíveis logo antes da aplicação da correção.
A ação principal para GitHub Enterprise Server é aplicar uma versão corrigida. As versões indicadas são 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 ou posteriores. A atualização deve ser priorizada porque a falha permite execução remota de código a partir de uma permissão que pode estar amplamente distribuída em ambientes de desenvolvimento. Após a atualização, a equipe deve validar que todos os nós da instância executam a versão esperada e que nenhum componente permanece em ramo vulnerável.
Antes e depois da correção, reduza a superfície de identidades capazes de acionar o vetor. Revise colaboradores, equipes, contas técnicas e integrações com permissão de push. Contas que não precisam mais escrever em repositórios devem perder essa permissão. Automação com privilégio amplo deve ser substituída por escopos menores quando possível. Embora a atualização elimine o caminho vulnerável conhecido, a redução de privilégios limita o dano caso surjam novas falhas em fluxos autenticados de Git.
A resposta também deve incluir revisão de hooks e configurações relacionadas. Repositórios que usam hooks de pré-recebimento ou políticas de validação devem ser comparados com uma linha de base conhecida. O ponto é confirmar que não há entradas inesperadas, caminhos manipulados ou configurações que tenham sido alteradas durante uma possível janela de exposição. Em instâncias próprias, logs de sistema, arquivos de configuração interna e registros de execução do usuário git devem ser preservados antes de limpezas agressivas, para não destruir evidência útil.
Equipes que operam arquiteturas internas semelhantes devem tratar CVE-2026-3854 como caso de estudo de falha em protocolo de serviço, não apenas como vulnerabilidade específica do GitHub. Dados controlados pelo usuário não devem ser serializados em formatos internos com delimitadores ambíguos sem escaping rigoroso, validação por esquema e separação entre campo de observabilidade e campo de controle. Quando metadados internos influenciam sandbox, caminhos de execução, hooks ou ambiente de processo, a validação deve ser centralizada e testada com entradas contendo delimitadores, campos duplicados e valores que tentem sobrescrever configuração crítica.
- Atualizar GitHub Enterprise Server para
3.14.25,3.15.20,3.16.16,3.17.13,3.18.8,3.19.4,3.20.0ou versão posterior aplicável. - Auditar usuários, equipes, integrações e contas de serviço com permissão de
git pushem repositórios sensíveis. - Revisar eventos de push e telemetria de hooks no período anterior à atualização.
- Verificar registros associados a
X-Stat, execução como usuáriogite alterações de ambiente durante processamento de envio. - Validar protocolos internos que transportam entrada de usuário com delimitadores compartilhados e remover dependência de campos injetáveis para decisões de segurança.
0 Comentários