Vulnerabilidades críticas em Zoom e GitLab exigem adesivo imediato

As plataformas que usamos diariamente para coordenar trabalho e projetos voltam a colocar a segurança no centro do debate: Zoom e GitLab publicaram adesivos para corrigir vulnerabilidades graves que, em diferentes cenários, poderiam permitir desde a interrupção de serviços até a execução remota de código. Estas atualizações chegam após auditorias internas e revisões que identificaram falhas que os administradores não podem ser ignoradas.

No caso de Zoom, o problema mais alarmante afeta os MMR (Multimedia Routers) de Zoom Node, componentes-chave quando se desenrolam soluções de reuniões em ambientes híbridos ou on-premise. De acordo com a empresa, foi detectada uma vulnerabilidade de injeção de comandos que, em versões anteriores à 5.2.1716.0, poderia permitir que um participante de uma reunião execute código na equipe que atua como MMR se tiver acesso à rede. O rastreamento desta falha aparece como CVE-2026-22844 e, por seu potencial impacto, recebeu uma pontuação CVSS de 9,9 sobre 10, o que indica uma ameaça crítica. Zoom publicou os detalhes e recomendações em seu boletim de segurança oficial aqui, e insta os clientes com implantaçãos de Zoom Node Meetings, Hybrid ou Meeting Connector a atualizar os módulos MMR à versão corrigida.

É importante salientar que, por agora, o Zoom não encontrou provas de que esta vulnerabilidade tenha sido aproveitada em ataques reais fora dos seus controles internos. Ainda assim, a combinação de um CVSS próximo a 10 e a natureza do vetor de ataque - um participante com acesso à reunião que poderia provocar execução remota na infraestrutura local - faz com que a recomendação de atualizar seja categórica. Se a sua organização gerir MMRs, Aplicar a actualização deve ser considerada uma prioridade operacional.

Paralelamente, GitLab publicou uma série de correções para sua Community Edition e Enterprise Edition após identificar múltiplas vulnerabilidades de alta e média severidade que poderiam provocar condições de recusa de serviço e, em um caso,burlar protecções de autenticação de dois fatores. A empresa descreveu na sua nota de lançamento as peças corrigidas e as versões afectadas; entre as mais críticas, encontram-se falhas que permitem aos usuários não autenticados desencadear DoS através de petições manipuladas e de um problema que poderia permitir a um atacante com conhecimento do identificador de credencial de uma vítima contornar a 2FA ao forjar respostas de dispositivo. GitLab publicou os adesivos e as informações técnicas na sua página de releases aqui.

Erros corrigidos por GitLab incluem CVE com pontuações altas, como CVE-2025-13927 e CVE-2025-13928, que permitem criar condições de indisponibilidade através de solicitações malformadas em diferentes APIs, e CVE-2026-0723, o qual afeta o fluxo de autenticação de segundo fator ao aceitar respostas forjadas. Além disso, foram resolvidos outros problemas de gravidade média que poderiam facilitar o DoS através de conteúdos Wiki especialmente construídos ou através de tentativas de autenticação SSH malformados. Para administradores de instâncias auto-alojadas, essas correções são essenciais para manter a integridade e a disponibilidade do serviço.

De uma perspectiva prática, a resposta adequada passa por aplicar adesivos quanto antes, verificar os registros para detectar padrões incomuns e, se possível, isolar componentes críticos até verificar que estão atualizados. Em ambientes onde a exposição da rede é difícil de controlar, convém rever as configurações de acesso a reuniões e os pontos de entrada ao serviço GitLab, e reforçar as políticas de autenticação e monitorização. Organismos como o MITRE mantêm registos públicos de CVE; por exemplo, o identificador de Zoom pode ser consultado CVE-2026-22844 no MITRE Para obter mais contexto técnico.

É compreensível que, perante alertas de segurança, surja um debate sobre a probabilidade de exploração face ao custo de aplicar atualizações em ambientes produtivos. No entanto, a história recente demonstra que as vulnerabilidades não corrigidas tendem a ser alvo rápido para a automação de ataques. Com ferramentas de descoberta e exploits cada vez mais acessíveis, uma falha com pontuações altas em CVSS pode se transformar em um vetor de ataque explorável em pouco tempo. Por isso, e embora não haja confirmação de ataques na natureza, a prudência orienta a agir sem demora.

Para equipamentos de segurança que gerem estas plataformas, o fluxo recomendado é claro: rever os avisos oficiais de Zoom e GitLab, comparar as versões feitas com as mencionadas nos boletins, planejar janelas de atualização com testes prévios e executar controles pós-parcheo para validar que não há regresões. Complementar essas ações com práticas como segmentação de rede, restrição de acesso a interfaces administrativas e ativação de alertas que detectem tentativas de exploração aumentará as barreiras frente a possíveis atacantes.

A disponibilidade de informação pública e a rapidez na comunicação por parte dos fornecedores são um ponto a favor. Zoom e GitLab disponibilizam administradores e usuários detalhes técnicos e guias de atualização em seus respectivos portais, o que facilita uma resposta coordenada. Além das páginas oficiais, convém seguir relatórios de organizações de cibersegurança e bases de dados de vulnerabilidades para obter contexto e recomendações adicionais.

No final, a lição é reiterada, mas necessária: em infra-estruturas críticas ou em colaboração em massa, a segurança não é uma adição, mas sim uma obrigação operacional. Manter por dia com adesivos, compreender o impacto de cada CVE e adaptar as políticas internas de gestão de alterações são passos fundamentais para reduzir riscos. Se a sua organização usa Zoom Node MMRs ou instâncias de GitLab afetadas, a melhor defesa hoje é atualizar e verificar.