Neste artigo
- Direto ao ponto
- O canal para reportar uma vulnerabilidade à empresa
- O relatório precisa permitir que os mantenedores reproduzam a falha
- A triagem pode alterar a gravidade sugerida
- A atribuição do CVE pode acontecer durante a correção
- Os prazos de divulgação dependem da política e do caso
- O problema na divulgação das falhas do Tailscale
- A correção precisa chegar à instalação afetada
Quando um pesquisador encontra uma falha de segurança em um software, ele normalmente avisa a empresa responsável por um canal privado e envia um relatório demonstrando como o problema acontece. A empresa usa essas informações para reproduzir a falha e desenvolver uma correção. Durante esse período, os detalhes da exploração ficam restritos às partes envolvidas para evitar que sejam usados em ataques enquanto o software continua vulnerável.
Esse processo é conhecido como divulgação coordenada e envolve um acordo sobre o acompanhamento da correção e a publicação dos detalhes. O identificador CVE (Common Vulnerabilities and Exposures) pode ser reservado durante a investigação e depois aparecer no comunicado público. Para você que encontrou uma falha e quer reportá-la, o contato com a empresa pode começar sem esse número: o relatório precisa mostrar o problema e as condições necessárias para reproduzi-lo.
Direto ao ponto
Procure a política de segurança da empresa, confira o escopo autorizado e envie um relatório com produto, versão, condições de acesso, impacto e passos de reprodução. Depois, acompanhe a triagem e combine como serão tratados a correção, o identificador CVE e a divulgação. O prazo de 90 dias aparece em algumas políticas, mas precisa ser conferido para o caso que você está reportando.
O canal para reportar uma vulnerabilidade à empresa
O fornecedor costuma indicar na seção de segurança um endereço de email ou uma plataforma para receber relatos. Em projetos de código aberto, o repositório pode ter um arquivo SECURITY.md com instruções. Outra possibilidade é consultar o arquivo security.txt no endereço HTTPS do domínio, no caminho /.well-known/security.txt.
A RFC 9116 define esse arquivo e os campos que apontam para contato, política e meios de criptografia. Se a empresa disponibilizar uma chave pública para o envio, use as instruções correspondentes. Quando houver uma plataforma de bug bounty, leia quais produtos e tipos de teste ela aceita antes de enviar o relatório.
A existência de um canal de contato não concede permissão para testar qualquer sistema da empresa. Você precisa conferir o escopo da política e trabalhar com credenciais e ambientes autorizados. Se a descoberta ocorreu por acaso, documente o comportamento observado sem ampliar o acesso a registros de terceiros apenas para aumentar a demonstração.
O relatório precisa permitir que os mantenedores reproduzam a falha
Uma descrição como “o sistema permite acessar arquivos de outro cadastro” apresenta a consequência, mas deixa perguntas essenciais sem resposta. Os mantenedores precisam saber qual versão você testou, quais permissões estavam disponíveis e qual ação produziu aquele acesso. A diferença entre um perfil comum e um perfil administrativo pode mudar a interpretação do resultado.
A prova de conceito, ou PoC (Proof of Concept), reúne o necessário para demonstrar o comportamento. Pode ser uma sequência de ações com capturas de tela, uma requisição acompanhada da resposta ou um pequeno programa para laboratório. O formato deve facilitar a reprodução sem inserir credenciais reais no relatório ou executar ações destrutivas.
Um modelo preenchível para o envio privado pode ter esta estrutura:
Assunto: [tipo de falha] em [produto e componente]
Produto e versão testados:Ambiente autorizado usado no teste:Componente ou endereço afetado:Permissões e pré-requisitos:
Resumo:[Descreva o comportamento e as permissões necessárias para provocá-lo.]
Passos para reproduzir:1. [Preparação necessária.]2. [Ação que demonstra a falha.]3. [Resultado observado.]
Resultado esperado:Resultado observado:Impacto demonstrado:Prova de conceito e anexos:Mitigação ou correção sugerida, se conhecida:
Podem confirmar o recebimento e indicar o contato para acompanhamento?A empresa pretende solicitar um CVE para este caso?Qual cronograma podemos combinar para correção e divulgação?Preferência de crédito público: [nome, pseudônimo ou anonimato].Preencha o impacto com aquilo que o teste demonstrou. Ler um arquivo indevido não comprova automaticamente execução de comandos ou acesso a todos os cadastros. Se houver uma consequência adicional que você ainda não confirmou, descreva essa limitação. A sugestão de correção pode ajudar a investigação, mas entregar um patch não é condição para comunicar a vulnerabilidade.
A triagem pode alterar a gravidade sugerida
Depois do recebimento, os mantenedores verificam se conseguem reproduzir o problema e se já existe um relato equivalente. Eles podem solicitar outra versão da prova de conceito ou esclarecer uma configuração necessária. O guia da OpenSSF para mantenedores apresenta o recebimento e a coordenação como partes do tratamento da falha.
A discussão sobre gravidade precisa considerar as condições do ataque. O CVSS (Common Vulnerability Scoring System) descreve características como acesso necessário, privilégios e consequências técnicas. Você pode sugerir uma classificação, mas a empresa pode discordar se o teste depender de uma permissão ou configuração diferente daquela considerada inicialmente.
Registre essas condições no acompanhamento do relatório. Um ataque que exige acesso a um dispositivo já autorizado tem um alcance diferente de uma exploração disponível a qualquer conexão pela internet. O relatório precisa explicar como esse acesso inicial afeta a reprodução da falha.
A atribuição do CVE pode acontecer durante a correção
Uma CNA (CVE Numbering Authority) é uma organização autorizada pelo Programa CVE a atribuir identificadores e publicar registros dentro de seu escopo. O fornecedor pode ser uma CNA e cuidar dessa etapa. Quando não for, você ou a empresa podem procurar uma autoridade que cubra o produto ou encaminhe a solicitação adequadamente.
As normas das CNAs descrevem essa responsabilidade e o tratamento do escopo. A atribuição depende da avaliação da vulnerabilidade. Um erro funcional, um relato duplicado ou uma solicitação sem informações suficientes não asseguram um identificador novo.
Combine com a empresa a responsabilidade por essa solicitação para evitar encaminhamentos duplicados. O CVE pode permanecer reservado enquanto os detalhes ainda não são públicos. Depois, o registro publicado identifica o produto afetado e reúne referências sobre a falha. A NVD, mantida pelo NIST, utiliza registros CVE e acrescenta análises. São responsabilidades diferentes. Você não precisa aguardar a análise da NVD para enviar o relato ao fornecedor.
Os prazos de divulgação dependem da política e do caso
O Project Zero explica sua política de divulgação, que utiliza 90 dias em determinadas condições. Esse número não estabelece um prazo universal para empresas ou pesquisadores. A política pode prever exceções. Uma vulnerabilidade já explorada exige uma avaliação diferente daquela mantida em sigilo entre as partes.
A divulgação coordenada reúne as informações necessárias para você identificar uma instalação afetada e aplicar a correção ou a mitigação disponível. O guia do CERT/CC trata desse trabalho entre pesquisadores, fornecedores e coordenadores. O acompanhamento deve registrar o recebimento, as respostas e as datas combinadas. Se a empresa parar de responder, procure novamente os canais publicados e considere solicitar auxílio a um coordenador que aceite o caso.
A publicação pode ocorrer mesmo sem patch disponível. Nesse cenário, o comunicado precisa informar as limitações conhecidas e as mitigações existentes. Evite transformar uma data vencida em publicação automática de todos os detalhes de exploração sem reavaliar as consequências para as instalações afetadas.
O problema na divulgação das falhas do Tailscale
O caso Tailworm mostra por que a forma de divulgar uma vulnerabilidade também merece atenção. Na nota publicada com a pesquisa, Erica Windisch, da Cyberdione Labs, defende que a divulgação rápida pode reduzir o tempo até as correções. O relatório apresenta detalhes de exploração e mitigações, mas a versão consultada em 26 de outubro de 2026 não informa uma cronologia de contato privado com a Tailscale, resposta da empresa e prazo combinado para publicação.
Minha crítica está nessa divulgação sem uma correção confirmada e sem explicar quanto tempo o fornecedor teve para investigar. Os detalhes ajudam você a entender a falha, mas também podem orientar ataques às instalações afetadas. O relatório ser sobre software de código aberto não elimina a utilidade de coordenar a publicação com os mantenedores. A ausência dessa cronologia pública, porém, não permite afirmar que nenhum contato privado aconteceu ou que a empresa ignorou o relato.
No artigo sobre as vulnerabilidades do Tailscale SSH e o Tailworm, explico também por que resumir o caso como “Tailscale foi hackeado” prejudica a compreensão. Os ataques de SSH descritos partem de um dispositivo comprometido e autorizado. Essas condições precisam acompanhar a divulgação para você avaliar a exposição dos seus servidores.
A correção precisa chegar à instalação afetada
Um patch disponível ainda precisa ser distribuído e aplicado. O comunicado público deve permitir identificar as versões afetadas e a versão corrigida, além de explicar qualquer configuração temporária necessária. Créditos pela descoberta podem ser combinados durante a coordenação. Uma recompensa financeira depende das condições do programa de bug bounty e não decorre da atribuição do CVE.
Na administração dos seus servidores, confira a versão instalada e o procedimento indicado pelo fornecedor. O exemplo de correção do OpenSSH no Debian mostra por que a verificação continua depois da atualização do pacote. O changelog da Promovaweb também reúne publicações sobre atualizações de ferramentas para acompanhar essas mudanças.
Para desenvolver essa base de administração e manutenção de servidores, consulte a Formação DevOps. Se o seu projeto precisa de acompanhamento técnico para planejar testes e implantação, o Conselheiro de Tecnologia da Dev Side Studio pode ajudar a organizar esse trabalho.
Antes de enviar o relatório, confira se um mantenedor consegue repetir os passos usando somente as instruções e os anexos fornecidos. Remova segredos dos arquivos, registre a versão testada e inclua um contato para responder às dúvidas da triagem.
