Request Tracker e RTIR: XSS armazenado nos tickets

Resumo

O Request Tracker (RT) é um sistema de tickets de código aberto da Best Practical Solutions. O RT for Incident Response (RTIR) é a extensão usada por equipes de resposta a incidentes e CSIRTs para receber relatos, abrir incidentes e acompanhar casos. Em 30 de outubro de 2026, a CERT Polska publicou três falhas de XSS armazenado nesses produtos, encontradas em pesquisa própria por Mateusz Szymaniec:

• CVE-2026-105454 — no RT, a criação automática de links para URLs em conteúdo HTML de ticket não escapa a URL inserida no link.
• CVE-2026-105455 — no RTIR, os formulários de divisão de ticket e de criação de incidente exibem o assunto do ticket relacionado sem escape.
• CVE-2026-105456 — no RTIR, a extensão do filtro de HTML do RT libera qualquer link que contenha o marcador de link interno, inclusive links com o esquema javascript:.

Nos três casos, o atacante não precisa de conta: basta enviar uma mensagem para uma fila que aceite tickets de remetentes externos — configuração comum em filas que recebem e-mail do público e padrão no RTIR para relatos de incidente. O script executa no navegador de quem abre o ticket e age com os privilégios dessa pessoa, que normalmente é um analista de segurança.

A correção foi publicada em 29 de outubro de 2026, nas versões RT 5.0.11, RT 6.0.4 e RTIR 6.0.4. O NVD ainda não concluiu a análise dos três registros. Até 3 de novembro de 2026, nenhuma das três falhas constava no catálogo Known Exploited Vulnerabilities (KEV) da CISA, e o EPSS estava abaixo de 0,5%.

Por que este alerta é prioritário

• O vetor não exige autenticação e usa o canal de entrada de e-mail, que costuma ser aberto justamente para receber relatos externos.
• Nas falhas CVE-2026-105454 e CVE-2026-105455, o script roda quando o ticket ou o formulário é exibido, sem clique — o CVSS v4.0 classifica a interação como passiva (UI:P).
• O CVE-2026-105456 vale para a instância inteira do RT, e não apenas para as filas do RTIR, alcançando qualquer pessoa que possa inserir HTML em um ticket.
• A sessão comprometida é a de um analista de incidentes: ela costuma ter acesso a tickets sigilosos, dados de outras instituições e funções administrativas.
• A pontuação de 5,3 mede o impacto técnico, não o contexto. Em um sistema que concentra o tratamento de incidentes, a mesma falha pode expor relatos sensíveis e permitir ações em nome da equipe.

Gravidade e exposição

Status de exploração: até 3 de novembro de 2026, não há relato público de exploração em ambiente real nem PoC citado nas fontes consultadas. A ausência de confirmação não indica segurança: a falha é acionada por e-mail e não depende de interação ativa da vítima em dois dos três casos.

O risco se concentra em instalações que recebem e-mail de fora — filas com CreateTicket ou ReplyToTicket liberados para Everyone e, no RTIR, a fila de Incident Reports, aberta a todos por padrão. Instalações fechadas, em que só usuários autenticados criam tickets, reduzem o alcance mas não eliminam a falha: qualquer pessoa que consiga inserir HTML em um ticket pode armazenar o payload.

Detalhes técnicos

O RT mantém o histórico de cada ticket e permite conteúdo em HTML. Ao exibir esse conteúdo, o RT converte URLs em links automaticamente. Na CVE-2026-105454, a URL usada para montar o atributo href não passa por escape de HTML: uma URL construída para encerrar o atributo pode inserir novos elementos, incluindo um script. O conteúdo é gravado no ticket e executado sempre que o histórico é aberto, sem ação adicional de quem visualiza.

No CVE-2026-105455, o problema está nos formulários do RTIR. Ao dividir um ticket ou ao criar um incidente a partir de um relato, o formulário mostra o assunto do ticket relacionado sem escape de HTML. Como o RTIR concede a Everyone o direito de criar Incident Reports por padrão, o assunto pode ser definido por um remetente de e-mail não autenticado. O script roda na sessão do analista que abre o formulário.

O CVE-2026-105456 é uma falha na extensão que o RTIR faz no filtro de HTML do RT. O RTIR permite um marcador para links internos, e a regra aceita qualquer link que apenas contenha esse marcador — inclusive com o esquema javascript:, que executa código ao ser clicado. A regra alterada vale para a instância inteira do RT depois que o RTIR é instalado, não só para as filas do RTIR. Nesse caso, a execução depende do clique no link.

Os três registros usam o mesmo vetor CVSS v4.0, com VC:L/VI:L e escopo alterado (SC:L/SI:L): o impacto direto é baixo, mas o script pode agir sobre outros componentes da aplicação com os direitos do usuário autenticado. A causa raiz é a mesma família de erro — saída de conteúdo sem escape contextual — em três pontos diferentes do RT e do RTIR.

A mesma atualização corrige outras falhas de segurança no RT e no RTIR, incluindo bypass de autorização, CSRF e divulgação de informação por URL de feed. Quem atualiza para corrigir estes XSS recebe também essas correções; os detalhes estão nas notas de versão.

Versões afetadas e correção

O CVE-2026-105455 não afeta o RTIR 5.0. As notas do RTIR 6.0.4 recomendam atualizar o RT para 6.0.4 junto com o RTIR, para compatibilidade e para receber as correções do RT. A tabela de versões afetadas do advisory da CERT Polska usa a forma “de 5.0.0 a 5.0.11”; a versão 5.0.11 é a corrigida e não deve ser tratada como vulnerável.

Como verificar

Confirme a versão do RT e do RTIR na instalação:

perl -MRT -e 'print "$RT::VERSION\n"'

grep -m1 'VERSION' /opt/rt/lib/RT/IR.pm

Ajuste o caminho do RTIR conforme a instalação. Ambientes com empacotamento próprio devem conferir a versão do pacote e o changelog do mantenedor: a correção pode ter sido aplicada por backport sem mudança no número principal.

Detecção

Não há evento isolado que identifique a exploração. A detecção combina a busca por conteúdo HTML suspeito nos tickets com a revisão das ações executadas nas sessões dos usuários, sobretudo contas com privilégios administrativos.

Conteúdo dos tickets

Procure transações que contenham scripts, manipuladores de evento ou o esquema javascript: em atributos. O RT guarda o conteúdo das mensagens na tabela Attachments; ajuste o filtro de data e limite o resultado para não sobrecarregar a base:

SELECT id, Ticket, Subject, Created
FROM Attachments
WHERE Created > now() - interval '30 days'
  AND (Content ILIKE '%<script%'
       OR Content ILIKE '%javascript:%'
       OR Content ILIKE '%onerror=%')
ORDER BY Created DESC
LIMIT 200;

O resultado é uma pista, não uma prova: mensagens legítimas podem citar trechos de código, relatos de phishing ou amostras de ataque. Confirme o contexto, o remetente e o que o ticket continha antes de tratar como exploração.

Sessões e ações

• Revise o histórico de transações de tickets criados por e-mail externo, com atenção a mudanças de proprietário, fila, prioridade ou status feitas por contas que não costumam atuar naquele ticket.
• Verifique criação de usuários, alteração de direitos, mudança de configuração e exportação de dados nas contas com privilégios elevados.
• Correlacione o horário de abertura de tickets suspeitos com acessos ao RT nos logs do proxy reverso e com autenticações fora do padrão.
• No RTIR, priorize a fila de Incident Reports e os formulários de divisão de ticket, que são o caminho de entrada descrito pelos pesquisadores.

A presença de um e-mail com HTML em uma fila pública não é prova de exploração, e a ausência de alerta do antivírus ou do gateway não prova que o conteúdo era seguro: o payload é HTML interpretado pelo navegador, não um anexo executável.

Recomendações

1. Inventarie as instalações de RT e RTIR. Inclua instâncias internas, ambientes de teste, cópias restauradas de backup e serviços usados por equipes de resposta a incidentes.
2. Atualize para RT 5.0.11 ou 6.0.4 e RTIR 6.0.4 (ou RTIR 5.0.11 na linha 5.0). Siga as notas de versão e faça backup antes; a atualização do RTIR 6.0 acompanha a do RT 6.0.
3. Revise os direitos de Everyone. Restrinja CreateTicket e ReplyToTicket nas filas que não precisam aceitar e-mail externo e revise as filas do RTIR abertas a relatos públicos.
4. Reduza a superfície de entrada. Onde possível, limite quem pode enviar e-mail para as filas e prefira autenticação de remetente para tickets internos.
5. Defesa em camadas no navegador. Uma política de segurança de conteúdo (CSP) restritiva no proxy reverso reduz a execução de script injetado, mas exige teste: o RT usa JavaScript próprio e pode precisar de exceções.
6. Faça hunting retroativo. Revise os últimos 30 dias de tickets com HTML suspeito e as ações de contas administrativas no período.
7. Proteja as sessões dos analistas. Exija contas individuais, sem compartilhamento, com o menor privilégio necessário, e mantenha o hábito de abrir tickets de remetentes desconhecidos em uma sessão sem privilégios administrativos.
8. Não confunda correção com limpeza. Atualizar remove a falha, mas não desfaz ações executadas por um script que já tenha rodado. Em caso de suspeita, trate como incidente e siga a seção de resposta.

Mitigação temporária

Resposta a incidentes

Se houver indício de que um ticket executou script, trate as sessões dos usuários que abriram o ticket como potencialmente comprometidas. Atualizar o sistema não invalida ações já executadas nem sessões já sequestradas.

1. Contenha: preserve o ticket, as transações e os cabeçalhos da mensagem original; identifique todos os usuários que visualizaram o conteúdo suspeito.
2. Investigue: reconstrua a linha do tempo entre a criação do ticket e as ações das contas expostas; revise transações, criação de usuários, mudanças de direitos e exportações.
3. Eradique: aplique a versão corrigida, remova o conteúdo malicioso dos tickets e encerre as sessões ativas das contas afetadas.
4. Recupere: redefina senhas e tokens das contas expostas, valide as configurações de direitos e acompanhe acessos anômalos após o retorno.
5. Notifique: acione o SOC da GigaCandanga e os canais oficiais (CTIR Gov, CERT.br). Avalie obrigações de notificação de incidente e de proteção de dados pessoais, inclusive sob a LGPD, se relatos de terceiros tiverem sido expostos.

Referências

Links externos abrem em nova aba. Consulte sempre a fonte oficial para o status mais recente.

• CERT Polska · Vulnerabilities in Request Tracker and RT for Incident Response software CERT Polska · 30 out. 2026
• CVE-2026-105454 · Stored XSS via crafted URLs in HTML ticket content in Request Tracker CVE Program · 30 out. 2026
• CVE-2026-105455 · Stored XSS via related ticket subject on RTIR forms CVE Program · 30 out. 2026
• CVE-2026-105456 · Stored XSS via HTML scrubber rule in RTIR CVE Program · 30 out. 2026
• Best Practical · RT 6.0.4 release notes Best Practical Solutions · 29 out. 2026
• Best Practical · RT 5.0.11 release notes Best Practical Solutions · 29 out. 2026
• Best Practical · RTIR 6.0.4 release notes Best Practical Solutions · 29 out. 2026
• NVD · CVE-2026-105454 Detail NIST NVD · análise pendente em 3 nov. 2026
• CISA · Known Exploited Vulnerabilities Catalog CISA · catálogo 2026.10.30

Outras fontes de consulta para resposta e investigação estão em Links úteis.

Revisão

Revisão 1.0 — 3 de novembro de 2026 — Publicação inicial. Fontes consultadas até 3 de novembro de 2026: advisory da CERT Polska, registros do CVE Program, notas de versão do RT 5.0.11 e 6.0.4 e do RTIR 6.0.4, NVD, CISA KEV e EPSS. O NVD ainda não publicou análise própria; a pontuação usada é a do CNA.

Este alerta consolida informações públicas e tem caráter informativo. Não substitui os comunicados oficiais dos fornecedores nem a avaliação da equipe responsável por cada ambiente. Teste as ações em ambiente controlado antes de aplicá-las em produção.

Última atualização: 3 de novembro de 2026.