Responsible Disclosure

Responsible disclosure WordPress é a prática ética de reportar uma vulnerabilidade ao desenvolvedor responsável antes de torná-la pública, dando tempo para que ela seja corrigida sem expor os usuários a risco. É padrão da indústria de segurança e a base do trabalho de pesquisadores que descobrem falhas em plugins, temas e até no core do CMS. Sem essa coordenação, cada CVE viraria uma janela aberta para ataque imediato.

O que é responsible disclosure

O conceito é simples: quem encontra uma vulnerabilidade entra em contato direto com quem mantém o software, descreve o problema com detalhes técnicos suficientes para reprodução, combina um prazo de correção e só publica os detalhes depois que a correção foi disponibilizada para os usuários. É um pacto ético entre pesquisadores e fornecedores.

O alvo principal é proteger o usuário final. Se um pesquisador publica os detalhes de uma falha antes da correção, expõe milhões de sites à exploração imediata. Se ele guarda a falha para sempre, ninguém aprende com o caso e o ecossistema não evolui. A divulgação responsável encontra o equilíbrio: corrige primeiro, divulga depois.

O prazo padrão da indústria é de 90 dias, popularizado pelo Project Zero do Google. Contagem começa no envio inicial do relatório. Se o desenvolvedor não responder ou não corrigir no prazo, o pesquisador tem o direito de divulgar publicamente — pressionando a comunidade a tomar ações de mitigação. É a forma de evitar que falhas fiquem indefinidamente sem correção.

O termo divulgação responsável aparece também como coordinated disclosure (CISA usa esse nome) ou ainda como vulnerability disclosure policy (VDP). São variações que apontam para a mesma prática: comunicação coordenada entre quem descobre e quem corrige, com cronograma definido.

Por que é importante para WordPress

WordPress roda em mais de 40% da web, e seu ecossistema tem dezenas de milhares de plugins ativos. Cada plugin é um vetor potencial de vulnerabilidade. Quando alguém descobre uma falha crítica em um plugin com 100 mil instalações, a divulgação imediata sem coordenação significa 100 mil sites expostos no mesmo dia.

Pelo padrão de responsible disclosure, o pesquisador reporta primeiro ao autor do plugin. O autor publica uma versão corrigida no repositório oficial. O WordPress dispara atualizações automáticas para sites que tenham essa opção ligada. Só depois, o pesquisador publica os detalhes técnicos da falha — geralmente acompanhados de um identificador CVE.

Esse fluxo evita uma corrida desigual entre administradores de site (que precisam atualizar manualmente em alguns casos) e atacantes (que escaneiam a web em massa por sites vulneráveis). Sites bem configurados pegam a correção em horas; sites abandonados ficam expostos, mas pelo menos o caminho de defesa estava aberto.

Empresas como WPScan, Wordfence e Patchstack mantêm programas formais de disclosure que coletam relatórios, validam, coordenam com os autores e publicam os CVEs depois da correção. São intermediários que profissionalizam o processo e dão respaldo aos pesquisadores que reportam.

Como reportar uma vulnerabilidade

O primeiro passo é encontrar o canal certo. Plugins maduros expõem um arquivo SECURITY.md no GitHub, uma página de security policy no site oficial ou um endereço de email dedicado (security@dominio). Use sempre esses canais. Mande o relatório por GitHub Issue público é o oposto de divulgação responsável.

O relatório precisa ter conteúdo técnico suficiente. Inclua: descrição da falha, versão afetada, passo a passo de reprodução, prova de conceito (PoC) se aplicável, impacto potencial e sugestão de mitigação se você tiver. Quanto mais clara a evidência, mais rápido o autor consegue corrigir.

Se o autor não responder em uma semana, é razoável escalar para um intermediário. WPScan aceita relatórios via wpscan.com/submit. Patchstack tem programa próprio. Wordfence Intelligence também. Esses serviços fazem a ponte e, em casos críticos, ajudam a coordenar bloqueio temporário no repositório oficial enquanto a correção sai.

Para projetos comerciais ou sites grandes que querem incentivar pesquisadores, vale publicar uma política formal. A FULL Services, por exemplo, é uma CNA reconhecida — atribui CVEs aos plugins que mantém — e segue cronograma público de disclosure para vulnerabilidades reportadas. Esse padrão sinaliza que a empresa leva segurança a sério e respeita o trabalho de quem encontra falhas.

Bug bounty e divulgação

Bug bounty é a evolução comercial da divulgação responsável: o desenvolvedor oferece recompensa em dinheiro para quem reportar falhas dentro do programa. Plataformas como HackerOne, Bugcrowd e Intigriti centralizam programas de centenas de empresas, definindo escopo, regras de engajamento, valores por severidade e canal seguro de comunicação.

No ecossistema WordPress, programas formais de bug bounty existem para o core via HackerOne (Automattic), para plugins enterprise como WooCommerce e para soluções comerciais. Pequenos plugins gratuitos raramente pagam bounty, mas reconhecem o pesquisador no changelog e no advisory público — capital de reputação que vale ouro em segurança ofensiva.

Já a divulgação não-responsável (full disclosure imediato sem coordenação) é considerada irresponsável e pode resultar em ações legais em algumas jurisdições. O caminho profissional é sempre coordinated disclosure: tentar contato, esperar prazo, escalar via intermediário se necessário, e publicar só depois da correção. Quem joga assim conquista respeito da indústria e abre portas para programas pagos.

Lidar com vulnerabilidade de plugin desatualizado em produção é um problema real para qualquer site WordPress sério. Para reduzir o risco antes do disclosure chegar, a FULL Services entrega o AIOS (All-In-One Security) já licenciado dentro da stack profissional, com firewall, monitoramento contínuo e bloqueio automático de tentativas conhecidas de exploração. Em vez de reagir só quando o CVE é publicado, você roda com camadas de defesa que ganham tempo para aplicar a correção sem comprometer o site.