Aprenda a corrigir as vulnerabilidades CVE-2026-6841, CVE-2026-41073, CVE-2026-41075 e CVE-2026-41076 no Request Tracker (Debian). Guia prático com comandos reais, script de automação, mitigação alternativa com iptables e proxy reverso, e livro recomendado sobre hardening de servidores Linux.
Em meados de 2026, a equipe de segurança do Debian divulgou correções importantes para múltiplas vulnerabilidades no Request Tracker (RT) — sistema amplamente utilizado para gerenciamento de chamados (tickets) em empresas de tecnologia, provedores de internet e times de suporte. As falhas identificadas incluíam:
- CVE-2026-6841 – XSS refletido via parâmetro "Page" em requisições GET, permitindo execução de JavaScript arbitrário no navegador da vítima.
- CVE-2026-41073 – Ataque que pode levar à execução remota de código em versões anteriores à 5.0.10 e 6.0.3.
- CVE-2026-41075 e CVE-2026-41076 – Escalação de privilégio, vazamento de informações e possíveis injeções SQL.
Se o seu RT ainda está rodando uma versão desatualizada, este conteúdo é para você. A seguir, você encontra um guia prático, reutilizável, com comandos reais, automação e mitigação alternativa — tudo focado em Debian Linux.
Como verificar se você está vulnerável
Antes de aplicar qualquer correção, confirme a versão do pacote request-tracker4 instalada no seu servidor:
dpkg -l request-tracker4
O comando retornará algo como:
ii request-tracker4 4.4.6+dfsg-1.1+deb12u3 amd64 Extensible trouble-ticket tracking system
Compare a versão com as versões seguras (fixed) para cada distribuição Debian, conforme o tracker oficial:
Se a sua versão for inferior à corrigida (por exemplo, termina com u3 ao invés de u4 ou u5), você está vulnerável.
Script de automação para aplicar a correção
Use o script Bash abaixo para automatizar completamente a atualização segura do Request Tracker. Ele atualiza a lista de pacotes, instala a correção e reinicia os serviços necessários.
#!/bin/bash # fix-rt-security.sh - Aplica correção de segurança no Request Tracker (Debian) # Uso: sudo bash fix-rt-security.sh set -e # interrompe o script se qualquer comando falhar echo "[1/4] Atualizando lista de pacotes..." apt update echo "[2/4] Aplicando atualização de segurança do request-tracker4..." apt upgrade -y request-tracker4 echo "[3/4] Reiniciando serviços relacionados ao RT..." systemctl restart apache2 # ou nginx, dependendo do seu servidor web systemctl restart rt4-fcgi # se estiver usando FastCGI echo "[4/4] Verificando versão instalada após correção..." dpkg -l request-tracker4 echo "✅ Correção aplicada. Consulte os logs em /var/log/apt/history.log para detalhes."
Para executar:
chmod +x fix-rt-security.sh sudo ./fix-rt-security.sh
Dica profissional: Agende atualizações automáticas de segurança com o pacote unattended-upgrades para evitar ficar vulnerável novamente no futuro.
📗 Recomendação de Leitura
Segurança em servidores Linux: Ataque e Defesa (anúncio) -> https://amzn.to/4ochVDk
Se você prefere estudar em português e quer aprender a "pensar como um hacker" para se antecipar a invasões, essa é a pedida! O livro ensina a usar as ferramentas prediletas dos invasores (como Nmap e Netcat) a seu favor, blindando seus sistemas.
Eu ganho uma comissão quando você faz uma compra.
Mitigação alternativa caso não possa atualizar agora
Se por qualquer motivo você não puder atualizar o RT imediatamente, aplique pelo menos uma das mitigações abaixo para reduzir o risco:
1. Restrição por IP com iptables (contra acesso indevido)
Libere acesso apenas para IPs internos confiáveis:
# Bloqueia acesso externo à porta 80 (HTTP) do RT iptables -A INPUT -p tcp --dport 80 -j DROP # Permite acesso apenas da rede interna 192.168.1.0/24 iptables -I INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT # Salva as regras (Debian) apt install iptables-persistent iptables-save > /etc/iptables/rules.v4
2. Limitação de taxa (rate limiting) para conter ataques de força bruta
# Cria uma chain específica iptables -N RATE_LIMIT # Aplica rate limiting: máximo 10 conexões por minuto, permitindo 3 em burst iptables -A RATE_LIMIT -m limit --limit 10/minute --limit-burst 3 -j ACCEPT iptables -A RATE_LIMIT -j DROP # Aplica à porta 443 (HTTPS) iptables -I INPUT -p tcp --dport 443 -j RATE_LIMIT
Referência prática sobre rate limiting em iptables.
3. Proxy reverso com cabeçalhos de segurança (nginx)
Se você já utiliza um proxy reverso (nginx, Apache, HAProxy) na frente do RT, adicione cabeçalhos de segurança para mitigar XSS e outros ataques:
# Exemplo para nginx add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "DENY" always; add_header X-XSS-Protection "1; mode=block" always;
Isso impede que o navegador execute scripts maliciosos injetados via parâmetros vulneráveis
Conclusão
As vulnerabilidades corrigidas no Request Tracker em meados de 2026 mostram como sistemas maduros ainda precisam de atenção contínua. A melhor estratégia de segurança combina:
1. Atualizações regulares automatizadas via unattended-upgrades.
2.Verificações proativas com os comandos e scripts fornecidos.
3. Mitigações complementares (iptables, proxy reverso) enquanto a correção oficial não pode ser aplicada.
4.Estudo contínuo de hardening, como o livro sugerido.
Aplique essas práticas hoje e mantenha seu RT protegido por muitos meses ou anos — independentemente da próxima CVE que surgir.
Nenhum comentário:
Postar um comentário