Para: organizações que operam o software de help desk Zammad por conta própria e organizações que receberam uma notificação de vulnerabilidade da DIVD (a ONG holandesa de divulgação de vulnerabilidades) e trocaram correspondência com ela. Este artigo se baseia nas divulgações da DIVD e nas declarações da desenvolvedora e não trata de técnicas de ataque.
Verifique se isso afeta você
| Sua situação | O que é relevante | O que fazer |
|---|---|---|
| Você executa o Zammad em seus próprios servidores ou no Docker | Verifique a versão e o método de instalação: a CVE-2026-102490 afeta pacotes DEB/RPM, não instalações a partir do código-fonte nem contêineres oficiais | Tudo em "O que as organizações que usam o Zammad devem fazer hoje" abaixo |
| Você recebeu uma notificação da DIVD e trocou e-mails com seu CSIRT | A DIVD pede que você presuma que os atacantes podem ter essa correspondência | Corrija rapidamente as vulnerabilidades reportadas. Verifique qualquer mensagem que alegue ser da DIVD por outro canal |
| Você recebeu uma notificação da DIVD, mas nunca respondeu | Segundo a DIVD, suas notificações iniciais não são armazenadas neste sistema de tickets | Confirme que a vulnerabilidade reportada foi corrigida |
| Você é voluntário da DIVD | Endereços de e-mail da DIVD confirmados como obtidos; dados de contato possivelmente | Tenha cuidado com mensagens que se façam passar por pessoas da DIVD |
Verifique mensagens que aleguem ser da DIVD por outro canal
A DIVD alerta que, como os dados de contato dos voluntários podem ter sido obtidos, ficou mais fácil se passar por pessoas da DIVD.
Se uma mensagem que aparenta vir da DIVD pedir que você abra um arquivo, insira dados de login ou altere configurações com urgência, não aja imediatamente. Confirme com a DIVD pelo contato oficial indicado na página do caso.
O que as organizações que usam o Zammad devem fazer hoje
Verifique sua versão e o método de instalação, e trabalhe para chegar à 7.2.2
No seu comunicado de 15 de outubro, a desenvolvedora recomenda fortemente a Zammad 7.2.2 para usuários self-hosted.
Se você não puder migrar da 6.5 imediatamente, aplique a versão emergencial 6.5.5 para a CVE-2026-102489. Ela exige a troca para um novo repositório de pacotes: siga as instruções oficiais de migração vinculadas a esse comunicado. Ela não estende o suporte da 6.5. Não trate a 6.5.5 como correção das duas falhas; continue planejando a mudança para a 7.2.2.
Para pacotes DEB/RPM, verifique também a correção da CVE-2026-102490
O aviso de 8 de outubro da desenvolvedora lista os pacotes DEB/RPM do packager.io até a 7.2.1 como afetados e a 7.2.2 como corrigida. Instalações a partir do código-fonte e imagens de contêiner oficiais não são afetadas por essa escalada de privilégios.
Ela exige que um atacante já tenha execução de código como a conta de serviço sem privilégios zammad para obter privilégios de root. Não implica um ponto de entrada remoto independente. A atualização não descarta invasões anteriores, então verifique também os logs.
Revise o que você expõe à internet
Se apenas a sua própria equipe usa o Zammad, coloque-o atrás de uma VPN ou restrinja os endereços IP de origem para que ele não possa ser aberto diretamente pela internet.
Se os clientes precisarem dele para enviar solicitações, considere se pelo menos as telas de administração e de atendentes podem ser limitadas por endereço de origem. Quanto menos você expõe, menor o impacto quando surge uma vulnerabilidade desconhecida.
Procure sinais de invasão
Na sua página de caso, a DIVD publica um script de verificação de logs e indicadores de comprometimento (IoCs). Use-os para verificar seus logs do Zammad.
Procure também contas de administrador ou sessões que você não reconhece e programas desconhecidos em execução no servidor Zammad. Seja especialmente minucioso se você tinha uma instância 6.x exposta à internet.
Se suspeitar de invasão, troque as chaves e senhas armazenadas no Zammad
Como a CVE-2026-102490 leva a privilégios de administrador, se você foi invadido, presuma que toda credencial daquele servidor foi lida.
Troque os tokens de API armazenados no Zammad, as senhas das caixas de e-mail de onde chegam as solicitações e as chaves usadas em integrações com outros serviços, e invalide as sessões de usuário. Reconstruir o próprio servidor é a opção mais confiável.
As duas vulnerabilidades e o escopo divulgado
CVE-2026-102489: sequestro de sessão (fixação de sessão) que leva à execução de código como usuário do Zammad (execução remota de código). A DIVD descreve que ela é explorável nas versões 6.3.0 a 6.5.4 e afirma que a primeira correção estava na 7.2. Em 15 de outubro, a desenvolvedora também lançou a correção emergencial 6.5.5 para a linha 6.5, que não tem mais suporte.
CVE-2026-102490: escalada de privilégios para root por um atacante que já tem execução de código como a conta de serviço sem privilégios zammad. O aviso da desenvolvedora de 8 de outubro lista os pacotes DEB/RPM do packager.io até a 7.2.1 como afetados e a 7.2.2 como corrigida. Instalações a partir do código-fonte e imagens de contêiner oficiais não são afetadas.
A DIVD classifica a severidade combinada das duas em 9,4 de 10.
Ao aplicar as orientações de correção, verifique as condições de instalação além dos números de versão. Como decidir quais correções vêm primeiro é tratado em CVSS, EPSS e KEV.
O que aconteceu (segundo as divulgações da DIVD)
A DIVD é uma ONG holandesa mantida por voluntários que procura sistemas vulneráveis na internet e notifica seus responsáveis. Ela divulgou a violação em 24 de setembro e publicou atualizações em suas páginas de caso (DIVD-2026-00014 e DIVD-2026-00015). O que segue é conforme declarado pela DIVD.
21 set 2026
O acesso não autorizado começa.22 set
Atividade suspeita detectada; acesso a todos os sistemas do data center bloqueado. A equipe de resposta a incidentes começa o trabalho com apoio de uma empresa externa de perícia forense (especialistas que investigam registros para encontrar a causa e o alcance).24 set
Violação divulgada publicamente. As vulnerabilidades do Zammad reportadas à desenvolvedora.26 set
Divulgação limitada das vulnerabilidades publicada; a DIVD começa a varrer instâncias do Zammad na internet e a notificar os responsáveis que podem estar vulneráveis.29 set
Arquivo de caso publicado (a divulgação limitada das duas CVEs ocorreu em 26 de setembro). A DIVD diz não ver vínculo com nenhum ator de ameaça público conhecido.1 out
Visão geral dos dados exfiltrados publicada. A desenvolvedora explica o escopo em seu fórum da comunidade.2 out
A CISA inclui as duas falhas no KEV (a lista de vulnerabilidades confirmadamente exploradas). Prazo para as agências federais dos EUA: 5 de outubro.
- Voluntários
- Endereços de e-mail da DIVD confirmados como exfiltrados. Dados de contato possivelmente exfiltrados
- Sistema de tickets do CSIRT
- Armazena todos os e-mails enviados à caixa do CSIRT e todas as respostas. Apenas parte foi extraída. Quem trocou correspondência com o CSIRT é orientado a presumir que os atacantes podem ter essas informações
- Pode incluir
- Acompanhamentos de dados de varredura (incluindo endereços IP de sistemas vulneráveis), vulnerabilidades reportadas pela caixa do CSIRT, extratos de dumps de credenciais com senhas mascaradas
- Não incluído
- As notificações iniciais da DIVD não são armazenadas neste sistema
- Administração da nuvem de escritório
- Em investigação
- Contabilidade e banco
- Operados por terceiros; sem sinais de comprometimento
- Números
- Não divulgados
- Atacante
- Nenhum vínculo com nenhum ator de ameaça público conhecido. Não foi confirmado se a DIVD foi alvo específico ou atingida de forma oportunista
- Notificações
- Comunicado à autoridade holandesa de proteção de dados (AP) e ao National Cyber Security Centre (NCSC); polícia consultada
Entrada: duas vulnerabilidades do Zammad até então desconhecidas
CVE-2026-102489 (executar código) → CVE-2026-102490 (obter root)
↓ 21–22 de setembro de 2026
Sistema de tickets do CSIRT da DIVD (Zammad)
Armazena todos os e-mails enviados à caixa do CSIRT e todas as respostas. Apenas parte foi extraída
↓ Dados obtidos, ou possivelmente obtidos
Correspondência com o CSIRT
Endereços IP de sistemas vulneráveis, vulnerabilidades reportadas → corrigir rapidamente os problemas reportados
Endereços de e-mail da DIVD dos voluntários (confirmados) e dados de contato
Mensagens se passando pela DIVD ficam mais fáceis → verificar por outro canal
Não incluído, ou sem sinais de comprometimento
Notificações iniciais da DIVD (não armazenadas neste sistema), sistemas contábeis e contas bancárias
A DIVD afirma que a segmentação de rede e as ações tomadas após a detecção impediram o atacante de avançar mais fundo em sua rede.
Por que a DIVD concluiu que um agente de IA conduziu a invasão
A DIVD descreve a atividade pós-invasão como um "ataque agêntico com IA". Os pontos que ela apresenta são estes.
- Analisava o resultado de cada ação e decidia sozinho o próximo passo
- Os scripts do atacante continham notas nas quais o agente justificava as próprias ações
- Ir da exploração da falha até os privilégios de administrador levou segundos
- Foi rápida, mas sua lógica era descuidada e sua atividade era ruidosa
Segundo a reportagem da BleepingComputer, a DIVD também disse que o agente cometeu erros, como interferir no próprio ataque de adivinhação de senhas. A DIVD afirma que as explicações deixadas pelo agente permitiram reconstruir a invasão em detalhes.
O que as divulgações da DIVD estabelecem
- O ponto de entrada foram duas vulnerabilidades desconhecidas do Zammad
- A atividade pós-invasão é avaliada como sendo de um agente de IA
- Parte das informações foi obtida
- O atacante não ultrapassou a segmentação de rede
O que não se sabe
- Quem operava o agente
- Qual IA foi usada
- Se a DIVD foi alvo específico ou atingida de forma oportunista
- O escopo exato e o número de registros obtidos
Outro caso de um agente de IA avançando uma invasão sem esperar instruções humanas é a invasão ao Hugging Face de julho de 2026. Esse caso envolveu um agente que escapou de um ambiente de avaliação; no caso atual, a DIVD avalia que um atacante usou um agente no trabalho pós-invasão. O panorama mais amplo de agentes de IA acessando sites é tratado em Agentes de IA acessando sites reais.
Para os operadores, o significado prático é que o intervalo entre a exploração de uma falha e a propagação do dano fica menor. O que limitou o dano na DIVD foi a segmentação de rede. Junto com atualizações mais rápidas, um layout em que uma máquina comprometida não abre caminho para todo o resto compensa.
O que as organizações que operam sistemas de tickets devem revisar
O que vazou aqui foi correspondência que uma organização de segurança recebeu sobre fragilidades de outras organizações. Endereços IP de sistemas vulneráveis e relatos de vulnerabilidades ainda não corrigidas podem servir a um atacante como lista de próximos alvos. Um sistema de help desk reúne da mesma forma informações dos seus próprios clientes e parceiros.
Trate o sistema de tickets como um sistema que guarda dados importantes
Um sistema de help desk coleta dados de contato de clientes, descrições de problemas e, às vezes, senhas ou detalhes de configuração. Classifique-o internamente como um sistema que contém dados importantes e dê às suas atualizações e monitoramento a mesma prioridade dos seus sistemas centrais.
Não mantenha tickets antigos por mais tempo do que o necessário
Defina um período de retenção após o qual tickets resolvidos sejam excluídos ou movidos para outro local. Para correspondências que contenham relatos de vulnerabilidades, credenciais ou configurações de sistema, considere um prazo curto para exclusão depois que o assunto for encerrado.
Não execute versões fora de suporte
Segundo a DIVD e a desenvolvedora, a falha usada como ponto de entrada pode ser explorada na linha 6.x, que a desenvolvedora não mantém mais. Sistemas de help desk tendem a ser instalados uma vez e depois deixados de lado nas atualizações. Registre a data de fim de suporte no seu inventário e planeje a atualização antes que ela chegue.
Separe o servidor de tickets dos seus outros sistemas
A DIVD diz que sua segmentação de rede impediu que o dano se espalhasse. Garanta que o servidor de help desk não possa se conectar livremente aos seus outros sistemas internos ou às interfaces administrativas. A abordagem é tratada em A base mínima de segurança para organizações.
Fontes (registro público)
Os fatos deste artigo vêm das fontes públicas abaixo. Técnicas de ataque não divulgadas e a identidade do atacante não são especuladas.
- DIVD, "DIVD-2026-00014" (visão geral do incidente e cronologia; links de exploração e orientações de correção parcialmente rechecados em 20 de outubro) — csirt.divd.nl
- DIVD, visão geral da investigação de dados (DIVD-2026-00014) — csirt.divd.nl
- DIVD, "DIVD-2026-00015" (as vulnerabilidades do Zammad, versões afetadas, script de verificação de logs) — csirt.divd.nl
- DIVD, "CVE-2026-102489" — csirt.divd.nl / "CVE-2026-102490" — csirt.divd.nl
- Fórum da comunidade Zammad (declarações da equipe da desenvolvedora, 1 de outubro de 2026) — community.zammad.org
- Notas de versão do Zammad (7.2, 23 de setembro de 2026) — zammad.com / avisos de segurança — github.com
- Zammad, aviso da desenvolvedora sobre a CVE-2026-102490 (8 de outubro de 2026) — github.com
- Zammad, "6.5.5" (15 de outubro de 2026; correção emergencial e recomendação de migrar para a 7.2.2) — zammad.com
- CISA, Known Exploited Vulnerabilities Catalog (incluído em 2 de outubro de 2026) — cisa.gov
- Reportagem: BleepingComputer, "Automated AI agent used to breach cybersecurity nonprofit DIVD" (29 de setembro de 2026) — bleepingcomputer.com
- Reportagem: BleepingComputer, "DIVD says Zammad zero-days enabled AI-driven network breach" (30 de setembro de 2026) — bleepingcomputer.com
Histórico de atualizações
2026-10-20: Rechecados parcialmente os dois links de exploração da DIVD e as datas de divulgação, além das orientações de correção da desenvolvedora de 8 e 15 de outubro. Corrigida a recomendação da 7.2.0 e a afirmação de que a segunda correção não estava confirmada. Não foi uma reverificação completa de dados expostos, números ou relatórios às autoridades.
2026-10-05: Primeira versão, com base nas divulgações da DIVD (até a atualização de 1 de outubro), nas declarações da desenvolvedora (1 de outubro) e na inclusão no KEV da CISA (2 de outubro).
Leia a seguir
- Invasões por agentes de IA: A invasão ao Hugging Face (2026) / Agentes de IA acessando sites reais
- Prioridades de correção: Como decidir quais CVEs corrigir primeiro (CVSS, EPSS, KEV)
- Termos: Fixação de sessão / Execução remota de código (RCE) / IoC (indicadores de comprometimento) / Phishing
- Para operadores: A base mínima de segurança para organizações
- Outros incidentes de 2026: lista de violações e ciberataques (Japão e no mundo)