Dois zero-days em software que roda em 30-40% de toda a internet. Um no reverse proxy que protege seu site. Outro no Git self-hosted que guarda seu código. Ambos exploráveis remotamente, sem autenticação, sem interação. Na Tech86, vimos essa combinação antes — e o padrão é claro: os pontos de entrada mais óbvios são os que ninguém audita.
NGINX PoolSlip: heap overflow no rewrite module
O CVE-2026-9256 é um heap buffer overflow no ngx_http_rewrite_module — o módulo que processa rewrite rules e redirects em toda configuração NGINX. CVSS v4.0: 9.2. Pre-auth, remoto, sem interação. Um único HTTP request craftado.
O gatilho: uma diretiva rewrite com regex de unnamed PCRE captures sobrepostos (^/((.*))$) combinada com uma replacement string que referencia múltiplos captures ($1$2). O NGINX subestima o tamanho do output após URI escaping — cada byte escapável expande de 1 para 3 bytes. O buffer é alocado para o tamanho raw. A cópia escreve além. Out-of-bounds write na memória do worker.
O impacto imediato é DoS por crash repetido do worker. Com ASLR desabilitado ou bypassável, o caminho para RCE no contexto do worker está aberto. E o pesquisador observa: o master faz fork de workers com layout idêntico — crashar um worker e tentar novamente é viável.
O padrão de configuração que ativa o PoolSlip não é exótico. Rewrite rules com capturas sobrepostas e múltiplos backreferences são comuns em API gateways, roteamentos dinâmicos e migrações de URL. Se o seu nginx.conf tem algo como rewrite ^/((.*))$ /new-path/$1$2;, você está na superfície de ataque. E a probabilidade de que alguém já tenha escaneado essa configuração com ferramentas automatizadas é alta.
Nove dias, dois heap overflows no mesmo módulo
Aqui está o ponto que não pode ser ignorado: CVE-2026-42945, o primeiro heap overflow no rewrite module, foi patchado nas versões 1.31.0 e 1.30.1. Quem atualizou para essas versões continua vulnerável ao PoolSlip. Bugs diferentes, mesmo código. Dois heap overflows em 9 dias no mesmo módulo não é coincidência — é sinal de que o rewrite engine precisa de auditoria profunda, não de patches incrementais.
O patch para PoolSlip está nas versões 1.31.1 e 1.30.2. O branch 0.x é EOL e não receberá correção. Verifique a versão do binário, não a versão do pacote do sistema operacional — a diferença é frequente e cara.
A mitigação imediata é substituir unnamed captures por named captures nas rewrite directives. Isso elimina o code path vulnerável sem necessidade de reboot. Mas é workaround, não solução estrutural. O rewrite engine do NGINX é um subsistema com estado compartilhado entre passes, escaping condicional e múltiplos code paths — exatamente o tipo de superfície onde bugs lógicos se acumulam sem detecção por anos.
Gogs: argument injection com RCE e sem patch
Enquanto o NGINX corrige em dias, o Gogs segue outro caminho. CVSS 9.4. Argument injection via branch name em pull requests. O atacante cria um branch com --exec no nome. Quando o merge usa "Rebase before merging", o comando é executado após cada commit replayed. RCE com privilégios do processo Gogs.
O que torna isso crítico: registro aberto por default, sem limite de repositórios. O atacante cria conta, cria repo, habilita rebase, explora. Nenhuma interação de outro usuário. É RCE self-contained. Com acesso ao processo, o atacante lê repos privados, dumpa credenciais, pivota para outros sistemas, modifica código em silêncio.
Rapid7 notificou o mantenedor em meados de março. Até 29 de maio: nenhum patch. Mais de dois meses. E esse é o segundo zero-day do Gogs em 6 meses — o primeiro, CVE-2025-8110, foi reportado pela Wiz em dezembro. Dois zero-days em meio ano, com resposta lenta em ambos, é um padrão que indica um problema estrutural de manutenção — não um incidente isolado.
Para times que dependem do Gogs como repositório central de código, a implicação é direta: cada dia sem patch é um dia em que a superfície de ataque cresce. Ferramentas de exploração automatizada tornam a descoberta e o abuso de vulnerabilidades como essa cada vez mais rápidos.
A lição: conveniência sem manutenção é alvo fácil
Gogs é popular porque oferece a conveniência de um GitHub privado sem custo. Times pequenos adotam pela simplicidade. Mas a combinação de registro aberto por default, ausência de patch por meses e dois zero-days em meio ano transforma essa conveniência em risco calculado — e o cálculo não favorece quem mantém a instância rodando.
Na Tech86, nossa recomendação é direta: migre para Gitea ou Forgejo. São forks do Gogs com manutenção ativa, correções de segurança consistentes e comunidade engajada. A migração é relativamente simples — ambos suportam importação direta de repositórios Gogs. Se a migração não é imediata, desabilite registro aberto, desabilite rebase merging e restrinja acesso por rede. Essas três medidas reduzem drasticamente a superfície — mas não eliminam a vulnerabilidade.
Conclusão
Dois zero-days. Dois softwares que rodam em escala global. NGINX: dois heap overflows em 9 dias no mesmo módulo, patch em dias mas a janela de exploração é real. Gogs: RCE sem patch há 2+ meses, segundo zero-day em 6 meses. Seu reverse proxy e seu Git self-hosted não podem ser os pontos de entrada da sua infraestrutura.
Na Tech86, auditamos infraestrutura web e pipelines de código com security-by-design. Identificamos configurações vulneráveis antes que se tornem exploits — e quando o patch não vem, construímos as camadas de defesa que protegem enquanto o problema estrutural não é resolvido. Porque em infraestrutura, o que não é auditado é explorado.