GitLab com 10,0 sob exploração, e o relógio de 24 horas do CRA

A semana teve um fio incomum, porque os dois itens que mais pesam não são do mesmo tipo. Um é uma emergência técnica: o GitLab publicou na quinta uma falha de nota 10,0 que deixa qualquer pessoa, sem credencial nenhuma, ler arquivo arbitrário do servidor. Na sexta de manhã já havia sondagem na internet aberta, e a CISA pôs a falha no catálogo de exploração ativa no mesmo dia, com prazo federal de três dias. O outro item não quebra nada: é uma data no calendário europeu. Desde 11 de setembro, quem fabrica software vendido na União Europeia tem 24 horas para avisar a ENISA quando descobre que uma vulnerabilidade do próprio produto está sendo explorada.

Os dois falam do mesmo assunto por lados opostos, e vale reparar nisso. No primeiro você é vítima da falha de outro e corre para atualizar. No segundo você é o fabricante, e o relógio começa a correr contra você. A maior parte de quem lê isto está nos dois papéis ao mesmo tempo e só pensou no primeiro.

Fora esse par, a semana foi de ferramenta. A DeepSeek soltou um modelo multimodal de um milhão de tokens sob licença MIT, o Chrome levou o segundo zero-day em cinco dias, a Cisco publicou um 10,0 no gerenciador de firewall sem contorno possível, o npm estendeu a trava de segurança para todas as contas, o GitHub Actions ganhou controle de acesso ao cache e a Cloudflare reescreveu o registro de módulos dos Workers. Oito itens. Três desenvolvidos.

Destaques

GitLab 10,0: leitura de arquivo sem autenticação, e a CISA mandou procurar rastro

Em 10 de setembro o GitLab publicou um patch crítico com dezessete correções de segurança nas versões 19.3.2, 19.2.6 e 19.1.8. A que importa é a CVE-2026-85706, nota 10,0: travessia de caminho na API de commits do repositório, que segundo o próprio aviso vem de confinamento de caminho mal feito somado a verificação de autenticação ausente. O resultado é usuário não autenticado lendo arquivo qualquer do servidor. Afeta CE e EE da 18.7 à 19.1.7, da 19.2 à 19.2.5 e da 19.3 à 19.3.1. Foi reportada por s3ntago pelo HackerOne. O GitLab.com já estava corrigido quando o aviso saiu.

A janela entre publicar e ser atacado foi de horas. A watchTowr registrou sondagem na internet aberta a partir das 06:00 UTC de 11 de setembro, e a CISA acrescentou a falha ao catálogo no mesmo dia, com prazo de correção para 14 de setembro. Há uma condição para explorar, e ela não protege quase ninguém: basta a instância ter pelo menos um projeto público.

O que muda na prática tem duas partes, e a segunda é a que costuma ser pulada. A primeira é óbvia: se você tem GitLab autogerenciado, sobe para 19.1.8, 19.2.6 ou 19.3.2 hoje. A segunda é que a CISA marcou a falha como caso de triagem forense sob a diretiva BOD 26-04, o que em português quer dizer que atualizar não encerra o assunto. Leitura arbitrária de arquivo em servidor de código não é leitura de código: é gitlab.rb, arquivo de log, variável de CI, token de registro, chave de deploy. Se a sua instância ficou exposta entre quinta e sábado, o trabalho depois da atualização é olhar log de acesso da API de commits e girar o que dava para ler. Correção fecha a porta, não invalida o que já saiu.

Vale registrar as outras duas do mesmo patch, porque quem vai atualizar de qualquer jeito precisa saber o que está levando junto. A CVE-2026-87719, nota 9,9, é desserialização insegura no serializador de subscrição GraphQL: usuário autenticado com acesso ao Duo Chat consegue configurações de busca avançada, e com elas credenciais. A CVE-2026-88765, nota 8,5, é estouro de buffer no conversor de Unicode e dá execução remota de código via exportação de projeto maliciosa, afetando EE desde a 12.3. Essa última importa para quem aceita importação de projeto de fora do time.

O relógio de 24 horas do CRA começou a contar, e ele é para você também

Entrou em vigor em 11 de setembro a obrigação de notificação do Cyber Resilience Act europeu. A página oficial da Comissão descreve o que passou a valer: fabricante de produto com elemento digital que toma conhecimento de vulnerabilidade sendo explorada ativamente, ou de incidente grave que afeta a segurança do produto, tem 24 horas para mandar um alerta inicial, 72 horas para a notificação completa com as medidas de correção e mitigação, e 14 dias para o relatório final. Tudo pela Single Reporting Platform, que a ENISA pôs no ar na mesma data. A notificação vai ao CSIRT coordenador e à ENISA de uma vez só.

Três detalhes decidem se isso é problema seu.

O primeiro é o escopo. A obrigação vale para produtos que já estão no mercado europeu, não só para o que for lançado daqui para frente. Não existe carência para o que você vendeu ano passado.

O segundo é quem conta como fabricante. Não é só quem vende caixa com firmware. Produto com elemento digital inclui software vendido ou disponibilizado no mercado europeu, e quem está fora da União Europeia mas vende para lá entra igual. Mantenedor de open source na figura de "steward" também entra, mas só em 11 de dezembro de 2027, o que dá dois anos e três meses de respiro para esse grupo específico.

O terceiro é quando o relógio começa. Não é quando você conserta nem quando você publica o aviso: é quando você toma conhecimento, e a orientação da Comissão de 27 de julho define isso como o momento em que uma avaliação inicial chega a certeza razoável de que há exploração ativa. Ou seja, o prazo corre a partir do seu próprio triage, e não a partir de quando você decide que já entendeu tudo.

O que muda na prática para quem opera software vendido na Europa: 24 horas é menos do que qualquer processo informal aguenta. Se hoje a descoberta de que "tem gente explorando aquilo" viaja por conversa em canal e vira reunião na semana seguinte, não dá. Precisa existir uma pessoa responsável, um caminho até a Single Reporting Platform que já tenha sido percorrido uma vez em treino, e um critério escrito de o que conta como certeza razoável. Fazer isso agora custa uma manhã. Fazer com o relógio correndo custa o prazo.

Para quem só atende cliente brasileiro, isso não vale hoje. Mas vale de olho: regra europeia de produto digital costuma virar referência de contrato aqui antes de virar lei, e cliente com operação na Europa vai começar a pedir isso em cláusula.

DeepSeek V4.1 Flash: um milhão de tokens, multimodal, sob MIT

A DeepSeek publicou em 10 de setembro o DeepSeek-V4.1-Flash, com peso aberto sob licença MIT. A ficha, tirada do cartão do modelo: 552 bilhões de parâmetros no tronco, mistura de especialistas que ativa 8 bilhões por token na leitura do prompt e 16 bilhões na geração, contexto de até um milhão de tokens, e processamento nativo de imagem e texto com saída em texto.

O preço da API própria deles está na tabela oficial: fora do horário de pico, 0,15 dólar por milhão de tokens de entrada sem cache, 0,003 com cache, e 0,60 de saída. No pico dobra tudo. Para efeito de comparação com o que eu registrei aqui semana passada, o GPT-6 Astra da OpenAI está em 10 dólares de entrada e 50 de saída, também com um milhão de contexto.

Eu não uso número de benchmark para decidir nada, então não vou repetir os deles. O que vale comentar é a forma. Dois pontos.

O primeiro é a licença. MIT em peso de modelo é o mais permissivo que existe na prática, sem cláusula de uso aceitável e sem limite de receita. Isso abre o caso de uso que licença de modelo aberto normalmente fecha: rodar dentro do ambiente do cliente, em dado que não pode sair, sem depender de contrato com laboratório. É a diferença entre "usamos IA" e "a IA roda aqui dentro", e para cliente com dado sensível essa distinção é a conversa inteira.

O segundo é a armadilha do MoE, e ela derruba muito projeto. Ativar 8 bilhões de parâmetros por token não quer dizer que você precisa de memória para 8 bilhões. Os 552 bilhões precisam estar carregados para que o roteador escolha qual especialista usar. O que a ativação esparsa barateia é computação, não memória. Quem ler "8B ativos" e orçar uma GPU de consumo vai descobrir isso no meio da implantação. Peso aberto de modelo grande é excelente notícia de soberania e péssima notícia de conta de hardware, e as duas coisas são verdade ao mesmo tempo.

Em nota

• Segundo zero-day do Chrome em cinco dias. A CVE-2026-87491 é escrita fora dos limites na V8 e entrou no catálogo da CISA em 9 de setembro, com prazo de 23 de setembro. Corrigida na 153.0.8010.36 e .37, no canal estável de 8 de setembro, e o Google diz saber que existe exploit em circulação. É a segunda em menos de uma semana: a anterior, que eu registrei aqui, tinha entrado no catálogo em 4 de setembro. A recomendação é a mesma e continua chata: feche e reabra o navegador, incluindo as máquinas da equipe que ficam ligadas há semanas.
• Cisco Secure FMC com 10,0 e sem contorno. A CVE-2026-20079 é desvio de autenticação na interface web do Secure Firewall Management Center que leva a root no sistema operacional, e entrou no catálogo em 9 de setembro. A análise da VulnCheck descreve a origem: um processo de inicialização cria uma sessão parcial no banco de sessões, e se ninguém autentica depois do boot ela fica lá para ser promovida. A Cisco diz que não há contorno. Na mesma leva entrou a CVE-2026-19490, o desvio de autenticação do Citrix NetScaler, que já tinha prova de conceito pública desde 2 de setembro. Servidor de gerenciamento de firewall é o que enxerga a rede inteira, e nos dois casos o caminho é atualizar, não mitigar.
• npm estendeu a trava de publicação para todas as contas. O changelog de 9 de setembro diz que entrada com código de recuperação agora segura publicação e criação de token por 72 horas em qualquer conta, e não só nas de alto impacto. Login e instalação continuam funcionando. É medida contra o padrão que se repetiu o ano inteiro: invadir a conta e publicar versão maliciosa na mesma hora. Se você mantém pacote e usa código de recuperação, conte com essa janela antes de um lançamento.
• GitHub Actions ganhou controle de acesso ao cache. O cache-mode chegou a disponibilidade geral e aceita read, write, write-only e none, no nível do workflow ou do job, valendo também em workflow reutilizável. O padrão já é seguro por evento: read para evento de baixa confiança como pull request, write para push. O alvo é envenenamento de cache, que é a rota silenciosa para injetar artefato em build de quem nunca leu o seu pull request. Se você aceita contribuição externa, vale declarar explicitamente em vez de confiar no padrão.
• A Cloudflare reescreveu o registro de módulos dos Workers. O texto de 9 de setembro conta a reescrita no workerd, tratando especificador de módulo como URL e não como caminho de arquivo. Na prática: import.meta.url e import.meta.resolve() funcionam, require(esm) segue a regra do Node, e as classes de erro ficam consistentes. Junto vieram compatibilidade com Node ligada por padrão e limite de aplicação de 64 mebibytes em todos os planos, sem limite de bundle comprimido. O registro novo é opt-in pela flag new_module_registry, que ainda não tem data para ligar sozinha. Se você desistiu dos Workers por causa de tamanho ou de pacote npm que não subia, o motivo pode ter deixado de existir.

O que eu faria com isso esta semana

1. Atualizar o GitLab autogerenciado hoje, e depois procurar rastro. As versões são 19.1.8, 19.2.6 e 19.3.2. Depois de subir, olhe log de acesso da API de commits no período entre 10 e 12 de setembro e gire token de CI, chave de deploy e credencial de registro que estivessem em arquivo legível. A própria CISA tratou o caso como de triagem forense, não como manutenção.
2. Escrever meia página sobre o CRA se você vende software para a Europa. Quem decide que houve exploração ativa, por onde a notificação sai, e o que conta como certeza razoável. Não precisa de advogado para a primeira versão. Precisa existir antes de o prazo de 24 horas começar a correr por conta de um aviso de terceiro que chegou numa sexta à noite.
3. Declarar cache-mode nos workflows que aceitam pull request externo. O padrão seguro cobre o caso comum, mas explícito é o que sobrevive a alguém mexer no workflow daqui a seis meses. Cinco minutos por repositório.
4. Refazer a conta do modelo aberto com memória, não com parâmetro ativo. Se alguém no time propôs rodar um MoE grande dentro do cliente por causa do "8B ativos", peça o cálculo de VRAM para o tronco inteiro antes de prometer qualquer coisa. É o tipo de número que muda a arquitetura, e é melhor descobrir na planilha.

Radar é a newsletter semanal deste blog: o que aconteceu na semana em tecnologia, com comentário sobre o que muda para quem constrói e opera software.