Do patch ao exploit em massa: 24 horas. Sua auditoria mensal não cabe nessa janela.

Reconstrua a linha do tempo do wp2shell:

Do "atualize, por favor" ao "está sendo explorado em escala": menos de 24 horas. Do patch ao carimbo oficial de exploração ativa: 4 dias.

Agora responda honestamente: em quantos dias a sua última varredura de segurança rodou?

Por que a janela encolheu

Não foi azar. Três coisas mudaram ao mesmo tempo.

Descoberta assistida por IA. A cadeia do wp2shell foi encontrada pela Searchlight Cyber com auxílio de modelo de linguagem — pouco mais de 10 horas de análise. Encadear uma confusão de rota na REST API com um SQL injection num parâmetro obscuro do WP_Query é exatamente o tipo de trabalho que antes dependia de um pesquisador sênior com semanas livres. Deixou de depender.

Weaponização quase instantânea. Publicado o detalhe técnico, o primeiro PoC funcional apareceu em horas, e mais de vinte variantes no fim de semana. O intervalo entre "sei que existe" e "tenho o script pronto" virou um turno de trabalho.

Varredura industrializada. As dezenas de milhares de tentativas registradas pela watchTowr saíram de 13 endereços IP. Isso não é gente testando site por site: é um alvo-lista global sendo percorrido por automação. Ninguém escolheu você. Você só estava na faixa de IP.

O resultado é uma assimetria brutal: o atacante opera em horas, e o modelo de defesa mais comum ainda opera em semanas.

O erro está no modelo, não no zelo

Auditoria periódica é uma foto. Você tira dia 1º, e ela responde perfeitamente à pergunta "como eu estava no dia 1º?".

O problema é que a maior parte do risco não nasce de uma mudança sua. Nasce de uma mudança no mundo: um CVE publicado dia 17 transforma retroativamente o seu site — que não mudou uma vírgula — de "nota B" em "RCE não autenticado". A foto do dia 1º não fica desatualizada porque você mexeu no site. Ela fica desatualizada porque o conhecimento público sobre o software que você já rodava mudou.

Escanear com mais frequência ajuda, mas não resolve a raiz, e cobra caro:

• Varredura ativa custa requisição no site do cliente. Diária em parque de 200 sites já incomoda hospedagem compartilhada.
• Mesmo diária, a janela média entre a publicação de um CVE e o seu conhecimento é de meio dia. Meio dia no ritmo do wp2shell é tarde.
• E rodar todas as probes toda hora, pra descobrir que 99% do parque continua igual, é queimar recurso pra confirmar o que já se sabia.

Já discutimos o parente dessa questão em pentest anual ou auditoria contínua. O wp2shell é o caso que fecha o argumento.

A inversão: pare de varrer, comece a cruzar

A ideia que resolve isso é simples de enunciar e chata de implementar:

Separe o inventário da avaliação.

A varredura serve pra responder o que você roda — versão do core, quais plugins, quais temas, quais endpoints expostos. Isso muda devagar: em site de cliente típico, semanas.

A avaliação responde o que isso significa hoje. E isso muda todo dia, porque o feed de vulnerabilidades muda todo dia.

Se as duas coisas estão amarradas — e no scanner tradicional estão, porque só se avalia enquanto se varre — você fica refém da cadência mais cara. Separando, você varre na cadência que o site aguenta e reavalia todo dia, sem tocar no site, contra o feed novo. O custo da reavaliação é uma query, não uma requisição HTTP.

Como o Sentinela implementa isso

Vou ser específico, porque "monitoramento contínuo" é frase que todo mundo escreve na home.

04:00 — o feed sincroniza. Um comando diário puxa o banco de vulnerabilidades WordPress da Wordfence Intelligence (com ETag, pra não baixar de novo quando nada mudou). Em paralelo, temos sincronização diária de feeds de malware (URLhaus, OpenPhish), do catálogo de vazamentos (HIBP), e o catálogo KEV da CISA com escore EPSS.

Em seguida — o parque é reavaliado. Uma varredura pega o inventário que a última auditoria de cada alvo já registrou (core, plugins, temas detectados, com versão) e cruza com o feed. Nenhuma requisição sai em direção ao site do cliente. É banco contra banco.

O que vira alerta. Piso de gravidade CVSS 7.0 — abaixo disso, a próxima auditoria agendada reporta normalmente, porque reavaliação retroativa existe pra urgência, não pra encher a timeline. Achado relevante emite o evento dependency.vulnerable no barramento operacional, que abre incidente em HIGH/CRITICAL e chega pelos canais que o cliente já configurou — e-mail, Slack, Discord, Telegram, webhook.

Três detalhes que só aparecem quando isso roda de verdade em produção:

O KEV faz o CVE voltar. Um CVE publicado com CVSS 6.5 fica abaixo do piso e é descartado. Três semanas depois, a CISA o adiciona ao KEV — e a gravidade efetiva sobe. A nossa varredura não trabalha com janela de tempo, e sim com marcador do que já foi dito por alvo; então esse CVE é reavaliado e passa no critério. Sem isso, teria ficado atrás da janela pra sempre. É exatamente o padrão do wp2shell: a percepção de gravidade mudou depois da publicação.

Inventário velho é pior que inventário nenhum. Alvo cuja última auditoria tem mais de 90 dias fica de fora. Um site que ninguém audita há um trimestre provavelmente já mudou, e alertar com base nele produz um falso positivo que não se corrige, porque o marcador de emissão é vitalício e queima aquele CVE para aquele alvo.

A primeira passagem não alerta. Alvo nunca reavaliado só tem os marcadores semeados, em silêncio. Sem isso, ligar a funcionalidade despejaria o backlog inteiro do feed na cara do cliente de uma vez — e a lição de todo sistema de alerta é que a primeira avalanche ensina o usuário a ignorar as próximas.

O outro gatilho: mudou, audita

A reavaliação cobre "o mundo mudou". Falta o inverso: você mudou.

Quando uma auditoria detecta mudança significativa na superfície — porta nova aberta, cabeçalho que sumiu, DNS alterado, TLS trocado, cookie diferente, ou um CRITICAL inédito — o sistema enfileira uma auditoria profunda automaticamente, sem esperar o próximo agendamento. Tem debounce de 60 minutos e um anti-loop rígido: auditoria disparada por evento nunca dispara outra.

Junte os dois gatilhos e você cobre as duas origens de risco:

E se você não usa o Sentinela

O modelo vale independentemente da ferramenta. Montado na mão, é assim:

1. Tenha um inventário versionado. Uma planilha com domínio, versão do core, plugins e versões já coloca você à frente da maioria. wp core version e wp plugin list --format=csv via WP-CLI, num cron que consolida.
2. Assine as fontes certas. O feed do KEV da CISA é o sinal de maior valor por byte que existe em segurança — e é gratuito. Some o feed de vulnerabilidades WordPress e o EPSS pra priorizar.
3. Cruze diariamente, não mensalmente. Um script que roda de manhã e responde "algum item do meu inventário aparece no que saiu ontem?" é meia página de código e resolve 80% do problema.
4. Ligue auto-update no core. Foi a atualização forçada do WordPress.org que segurou a contagem de vítimas do wp2shell. Versão travada custa mais caro do que o tema que ela protege.

O número que importa

Existe uma métrica que resume tudo isso, e não é a nota de A a F: quantas horas entre um CVE crítico ser publicado e você saber que ele te atinge.

Com auditoria mensal, a média é de 15 dias e o pior caso é 29. Com auditoria diária, meio dia. Com reavaliação de inventário contra feed, é o intervalo até a próxima sincronização — e o custo marginal disso é uma query.

No caso do wp2shell, a diferença entre esses números foi a diferença entre atualizar no sábado e passar o mês seguinte procurando web shell.

Se você quer ver a superfície do seu site — e ser avisado quando o mundo mudar de opinião sobre ela — comece por aqui. Se você administra parque de sites, a conta muda de figura: veja o post sobre agências.

Fontes

• WordPress wp2shell Exploitation Grows as Public Exploit Fuels Mass Scanning — The Hacker News
• WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030 — VulnCheck
• CVE-2026-63030: wp2shell, a Critical RCE in WordPress Core — Rapid7
• WP2Shell WordPress Vulnerabilities Exploited in the Wild — SecurityWeek