Política de Divulgação de Vulnerabilidades
A Estelaz mantém um programa de relato de vulnerabilidades com recompensa. Esta Política define o que está dentro e fora do escopo, quais condutas são autorizadas durante a pesquisa, como o valor de cada recompensa é definido, de que formas ela pode ser paga, o que o pesquisador precisa ter para receber e como funciona o cadastro que dá prioridade em relatos futuros.
Última atualização: 16 de setembro de 2026.
1. Objetivo
A Estelaz reconhece o trabalho da comunidade de segurança e mantém um programa de relato de vulnerabilidades, com canal dedicado e recompensa para os achados válidos. Esta Política descreve as regras dessa relação.
Relatos enviados de boa-fé e em conformidade com este documento são tratados como contribuição à segurança da plataforma, e não como tentativa de ataque.
2. Canal de relato
Relatos devem ser enviados para security@estelaz.com. Pedimos que o assunto identifique claramente que se trata de relato de vulnerabilidade.
Relatos enviados a outros canais podem demorar mais para chegar à equipe responsável.
3. Conteúdo do relato
Um relato útil descreve o componente afetado, o endereço acessado, os passos necessários para reproduzir o comportamento, o impacto observado e, quando possível, evidências como capturas de tela ou registros de requisição.
Pedimos que o relato indique a data e o horário aproximado dos testes, para facilitar a correlação com nossos registros.
4. Escopo
Estão no escopo o site institucional, o painel administrativo, o webmail, as APIs públicas, os serviços de recebimento e envio de mensagens e os aplicativos oficialmente distribuídos pela Estelaz.
5. Fora de escopo
Estão fora do escopo sistemas de terceiros que apenas integramos, serviços hospedados por clientes em domínios próprios, infraestrutura de provedores externos e qualquer alvo que não esteja sob nossa administração.
Relatos sobre esses alvos devem ser dirigidos ao responsável pelo respectivo sistema.
6. Achados geralmente não aceitos
Salvo demonstração de impacto concreto, não tratamos como vulnerabilidade a simples ausência de cabeçalhos recomendados, resultados brutos de ferramentas automatizadas, questões de configuração de e-mail em domínios sem envio, enumeração de usuários sem consequência prática, autopreenchimento de senha pelo navegador e ataques que dependam de acesso físico ao dispositivo da vítima.
Também não tratamos como vulnerabilidade relatos baseados apenas em versões de software identificadas por banner, sem prova de explorabilidade.
7. Condutas autorizadas
Durante a pesquisa, é autorizado acessar apenas dados da própria conta de teste, utilizar volume de requisições compatível com verificação pontual e interromper imediatamente a atividade ao identificar dados de terceiros.
Recomendamos criar conta específica para testes e identificar as requisições de pesquisa com cabeçalho ou parâmetro reconhecível.
8. Condutas não autorizadas
Não são autorizados ataques de negação de serviço, envio de spam ou phishing para usuários reais, engenharia social contra clientes ou integrantes da equipe, tentativa de acesso a contas de terceiros, modificação ou destruição de dados e uso de credenciais obtidas em vazamentos.
O programa recebe vulnerabilidades reais. Não recebe ataques cuja única finalidade seja sobrecarregar serviços que funcionam como esperado.
Também não é autorizado manter acesso persistente após a comprovação da falha, nem instalar qualquer componente em nossos sistemas.
9. Ataques de sobrecarga
Ataques de negação de serviço, distribuídos ou não, inundação de tráfego, esgotamento de conexões, envio massivo de mensagens e qualquer outra tentativa de derrubar ou degradar um serviço que esteja funcionando como esperado ficam fora do programa.
Sobrecarregar um serviço não demonstra vulnerabilidade: demonstra apenas que todo serviço tem capacidade finita. Esse tipo de atividade não gera recompensa, não é tratado como pesquisa e é conduzido como incidente de segurança, com as medidas cabíveis.
É diferente da falha que permite a um único pedido consumir recurso desproporcional, contornar um limite de uso ou derrubar um serviço com custo mínimo para quem ataca. Isso é vulnerabilidade real, está no escopo e deve ser demonstrado com o menor volume possível, sem repetir o efeito depois de comprovado.
10. Dados de terceiros
Se a pesquisa expuser dados pessoais de terceiros, o acesso deve ser interrompido imediatamente, o conteúdo não deve ser copiado ou divulgado e o fato deve ser informado no relato.
Cópias eventualmente obtidas devem ser eliminadas assim que a verificação estiver concluída, com confirmação enviada a nós.
11. Confidencialidade
Pedimos que a falha permaneça confidencial até que a correção seja publicada ou até o prazo acordado entre as partes, o que ocorrer primeiro.
A divulgação pública antes da correção aumenta o risco para usuários e afasta o relato das condições desta Política.
12. Prazos de resposta
Confirmamos o recebimento do relato em até três dias úteis, apresentamos avaliação inicial em até dez dias úteis e informamos o plano de correção após a validação.
O prazo de correção depende da severidade e da complexidade da falha. Mantemos o pesquisador informado sobre a evolução.
13. Classificação de severidade
Classificamos os achados considerando impacto sobre confidencialidade, integridade e disponibilidade, facilidade de exploração, necessidade de autenticação e alcance sobre a base de usuários.
14. Correção
Falhas críticas recebem prioridade sobre qualquer outra atividade de engenharia e podem ser corrigidas por medida emergencial seguida de correção definitiva.
Falhas de severidade menor são incorporadas ao ciclo regular de desenvolvimento.
15. Divulgação coordenada
Após a correção, podemos publicar descrição do problema e das medidas adotadas. O pesquisador pode ser mencionado com seu consentimento expresso.
Preferimos a divulgação conjunta, com alinhamento prévio de conteúdo e data entre as partes.
16. Recompensa
Relatos válidos podem ser recompensados. O valor de cada recompensa é variável e definido exclusivamente pela Estelaz, conforme a gravidade da falha e o momento em que o relato chegou.
Não há tabela fixa de valores, e um relato anterior não cria expectativa de valor para os seguintes. Relatar primeiro uma falha grave é o que mais pesa na definição.
17. Momento do relato
A gravidade usada no cálculo é a mesma da classificação de severidade descrita acima.
O momento considera se a falha já era conhecida por nós, se já estava em correção e se o relato chegou antes de qualquer exploração observada. Um relato que chega depois de a falha já ter sido identificada internamente vale menos que o mesmo relato chegando antes.
18. Relatos duplicados e recompensa
Quando mais de uma pessoa relatar a mesma falha, a recompensa integral cabe ao primeiro relato válido recebido.
O relato posterior pode receber valor reduzido quando trouxer informação que não estava no primeiro, como outro vetor de exploração, maior alcance do que se imaginava ou um caminho de correção que não havia sido considerado.
Quando se confirmar que o relato posterior não acrescentou nada ao anterior, não haverá recompensa para ele.
Sempre que a falha já tiver sido relatada por outra pessoa ou já estiver em correção, informaremos o fato ao pesquisador.
19. Formas de pagamento
A recompensa é paga principalmente em euro. Também pode ser paga em créditos na plataforma, utilizáveis na contratação e na renovação de planos.
Pagamento em criptomoeda é possível apenas em Bitcoin ou Litecoin, em casos muito específicos e com pesquisadores já conhecidos por nós. Não é uma opção aberta a qualquer relato.
A forma de pagamento é acordada antes da transferência, e a Estelaz não se obriga a atender a forma preferida pelo pesquisador.
20. Requisitos para receber
Para receber em créditos, o pesquisador precisa ter conta na Estelaz, onde o valor é lançado.
Para receber em euro, precisa ter conta bancária internacional na Europa apta a receber a transferência. Não realizamos pagamento em euro para contas fora dessa condição.
Quem não atender a nenhum dos dois casos ainda pode relatar, e o relato continua sendo analisado e corrigido, mas não haverá como efetuar o pagamento.
21. Encargos do pagamento
Tarifas bancárias, conversão de moeda e tributos devidos no país de residência do pesquisador são de responsabilidade dele.
Podemos solicitar dados de identificação antes de efetuar o pagamento, para cumprir obrigações legais e prevenir fraude.
22. Cadastro do pesquisador
O pesquisador pode se cadastrar no programa enviando e-mail para security@estelaz.com. Em resposta, recebe um código pessoal que identifica seus relatos daí em diante.
O cadastro não é obrigatório, e um relato sem código continua sendo recebido e analisado normalmente. Ainda assim, é bastante recomendado.
23. O que o código muda
Relatos que chegam com o código do pesquisador entram com prioridade na fila de análise e constroem um histórico conosco.
Esse histórico aumenta as chances de valores maiores quando isso for aplicável, e é o que viabiliza as formas de pagamento reservadas a pesquisadores já conhecidos.
O código é pessoal e não deve ser compartilhado. O uso por terceiros leva ao cancelamento do cadastro.
24. Reconhecimento público
Pesquisadores que contribuírem com relatos válidos podem ser reconhecidos publicamente em página de agradecimentos, mediante autorização expressa.
O reconhecimento é independente da recompensa: é possível receber um sem o outro, conforme a preferência do pesquisador.
25. Postura quanto a medidas legais
Não adotaremos medidas legais contra pesquisadores que atuem de boa-fé e em conformidade com esta Política, e que interrompam a atividade diante de qualquer exposição de dados de terceiros.
Esta postura não alcança condutas dolosas, extorsão, uso indevido de dados obtidos, ataques a disponibilidade e atividades fora do escopo definido.
26. Relatos com exigência de pagamento
O programa paga recompensa, mas quem define o valor é a Estelaz, depois de receber e validar o relato. Mensagens que condicionam a revelação de detalhes técnicos ao pagamento prévio, ou que estipulam um valor como condição para entregar a informação, não são tratadas como relato de boa-fé.
Esses casos ficam fora do programa, não geram recompensa e podem ser encaminhados às autoridades competentes.
27. Falhas em dependências
Falhas identificadas em componentes de terceiros utilizados por nós são encaminhadas ao respectivo mantenedor, e aplicamos mitigação enquanto a correção de origem não estiver disponível.
28. Dados pessoais do pesquisador
Os dados de contato informados no relato são utilizados apenas para conduzir a análise, comunicar a evolução e, quando autorizado, registrar o reconhecimento público.
Relatos anônimos são aceitos, com a ressalva de que não poderemos solicitar esclarecimentos nem informar o desfecho.
29. Testes autorizados por contrato
Clientes que desejem conduzir teste de intrusão contra recursos contratados devem solicitar autorização prévia por escrito para security@estelaz.com, informando escopo, período e origens utilizadas.
Testes conduzidos sem autorização podem acionar bloqueios automáticos e ser tratados como incidente de segurança.
30. Relação com outros documentos
Esta Política complementa a Política de Segurança Cibernética, os Termos de Uso e a Política de Uso Aceitável, que permanecem aplicáveis durante qualquer atividade de pesquisa.
31. Alterações desta Política
Esta Política pode ser alterada a qualquer momento. A versão aplicável a um relato é a publicada nesta página na data do envio.
32. Contato
Relatos e dúvidas sobre esta Política devem ser enviados para security@estelaz.com.
Dúvidas sobre este documento podem ser enviadas para contato@estelaz.com. Assuntos de privacidade e proteção de dados: dpo@estelaz.com. Denúncias de abuso: abuse@estelaz.com. Falhas de segurança: security@estelaz.com.
Outros documentos legais da Estelaz: