Em 90 dias, o programa de segurança do WordPress recebeu 2004 relatórios de vulnerabilidades e pagou por eles mais de 90 mil dólares. É quase metade de tudo o que pagou desde 2017. Até agora, quem pagava era uma só entidade, a Automattic. Na segunda-feira, 5 de outubro de 2026, Mary Hubbard, diretora executiva do WordPress, escreveu aos responsáveis de mais de 30 empresas a pedir que contribuíssem.
Escrevo com base no artigo do The Repository de 8 de outubro de 2026, que cita o e-mail de Hubbard (The Repository, 8 de outubro de 2026), e nos anúncios em wordpress.org. Não vi o e-mail em si. Os números e as citações foram verificados nas fontes a 9 de outubro de 2026.
O que Mary Hubbard pediu às empresas de alojamento e plugins
O e-mail foi enviado aos presidentes de empresas de alojamento, de plugins e de segurança ao fim da tarde, hora UTC. O The Repository fala em “segunda-feira à noite, UTC” (tradução própria) no texto de quinta-feira, 8 de outubro. A tese principal: a IA baixou o custo de encontrar falhas.
“A IA tinha feito desabar o custo de encontrar, comunicar e explorar vulnerabilidades”
Mary Hubbard, citada pelo The Repository, 8 de outubro de 2026, tradução própria
Segundo ela, em 90 dias o programa recebeu quase 2000 relatórios, mais do que alguma vez, “e o ritmo continua a subir” (tradução própria). O The Repository consultou a página do programa no HackerOne: 2004 relatórios e mais de 90 mil dólares em recompensas em 90 dias, para pouco mais de 200 mil dólares pagos desde o arranque, em abril de 2017.
“Quase metade de tudo o que o programa pagou desde sempre aconteceu num único trimestre, e a curva só vai num sentido.”
Mary Hubbard, citada pelo The Repository, 8 de outubro de 2026, tradução própria
Hubbard escreve também que a Automattic financiou o programa a 100%: cada recompensa, a triagem, a verificação, as correções e as versões de segurança coordenadas para todos os ramos suportados até ao WordPress 4.7. Pede uma de três coisas: uma contribuição para um fundo comum de recompensas, o patrocínio de pessoas para a triagem e as versões, ou outra forma, combinada em conjunto. Sublinha que parte do aumento são investigações genuínas que, graças às novas ferramentas, avançam mais depressa e melhoram de facto a segurança. O problema, na sua opinião, é a economia, não o programa em si: “O que está avariado é a economia, não o programa” (tradução própria).
Que empresas foram convidadas a financiar a segurança do WordPress
À cabeça da lista de destinatários estavam GoDaddy, Newfold Digital e Hostinger. O The Repository enumera depois:
| Grupo | Empresas |
|---|---|
| Alojamento e registadores | SiteGround, IONOS, DigitalOcean, DreamHost, World Host Group, Kinsta, OVHcloud, group.one, Namecheap, Tucows, Pantheon, Porkbun |
| Plugins e produtos | Elementor, Awesome Motive, Incsub (WPMU DEV), Rocketgenius (Gravity Forms), Rank Math, Brainstorm Force, Extendify |
| Agências enterprise | Human Made, rtCamp |
| Segurança | Wordfence, Patchstack, BlogVault |
Fonte: The Repository, 8 de outubro de 2026.
A WP Engine, que desde 2024 está em litígio judicial com a Automattic, não recebeu o e-mail, embora representantes da WP Engine tenham sido mencionados nos agradecimentos das versões de segurança 7.0.2 e 7.1.1. Também a Nexcess não constava da lista.
Como responderam as empresas de alojamento e plugins
Quem respondeu ao The Repository está a favor, mas quer saber exatamente ao que se compromete.
- Hostinger (Marco Chiesi): admite destacar pessoas suas. Desde julho colabora com a equipa de segurança e aplica regras de WAF antes da publicação das correções.
- Kinsta (Jon Penland): quer um programa “clearly defined” (claramente definido) para o qual as empresas possam contribuir.
- Awesome Motive (Syed Balkhi): já patrocina vários colaboradores das equipas de segurança e de plugins, mas observa que o pedido é “quite open-ended”.
- Human Made (Tom Willmot): patrocina John Blackbourn, que representa a equipa de segurança a tempo inteiro. A agência já tentou antes juntar empresas em torno de um fundo de segurança, “infelizmente sem grande adesão” (tradução própria).
- Patchstack (Oliver Sild): a empresa pagou do seu bolso 600 mil dólares em recompensas desde 2022, mas nunca foi admitida nas equipas de segurança e de plugins do WordPress. Na sua opinião, “este processo tem de ser reformado” (tradução própria).
GoDaddy, Newfold Digital e Wordfence não responderam até à publicação do texto.
WordPress 7.1.4: 22 vulnerabilidades e o que significam para o seu site
Atualização, . O WordPress 7.1.4 saiu a 28 de outubro. A página da versão conta 22 vulnerabilidades. A mais grave é uma condição de corrida no processo de atualização do núcleo que, segundo quem a reportou, Umut Bayram, podia levar a execução remota de código. A maioria das restantes são XSS armazenados que exigem pelo menos uma conta de colaborador. Dois relatórios são atribuídos à Anthropic. As correções foram levadas para ramos antigos, da 7.0.8 até à 4.7.39, e os sites com atualizações automáticas em segundo plano recebem o patch sozinhos.
É a sétima versão de segurança do núcleo desde julho. No balanço de dois meses da Core Security Initiative, Rudy Faile escreve que a equipa recebeu mais de 3000 relatórios este ano, mais do que nos doze anos anteriores juntos, e que 73 % dos 109 passos de uma versão de segurança já estão automatizados. A este ritmo, deixar a atualização de segurança para o fim de semana deixa de ser um hábito seguro. Nas minhas atualizações de WordPress as versões de segurança passam primeiro pelo ambiente de testes e só depois para produção.
O que corrige o WordPress 7.1.3 e quem reportou as falhas
Um dia depois do e-mail, a 6 de outubro de 2026, saiu o WordPress 7.1.3 com 7 correções de segurança e 4 outras correções de erros. No anúncio, cada correção indica quem a reportou:
| Vulnerabilidade | Quem a pode explorar | Reportado por |
|---|---|---|
| Stored XSS na página Comentários do painel, através de comentários pendentes | Qualquer pessoa que deixe um comentário, se um moderador (Editor ou superior) clicar numa ligação nele | Trail of Bits em colaboração com a OpenAI |
Negação de serviço em WP_Http::make_absolute_url() | Conta de Colaborador ou superior | Anthropic |
| SQL injection de segunda ordem na exportação WXR | Administrador que faz uma exportação, com um valor errado de _thumbnail_id já na base de dados | Anthropic |
| Um Autor podia fixar artigos (sticky) | Conta de Autor ou superior | Anthropic |
| Divulgação de comentários de artigos privados e não publicados | Qualquer pessoa, sem iniciar sessão | Ananda Dhakal, Patchstack |
| XSS em incorporações do Imgur | Conta de Colaborador ou superior e uma vítima que veja o artigo | Zhengyu Liu, Jingcheng Yang, Gavin Zhong |
Parâmetros forjáveis do hook {status}_{type} | Plugin que passe a wp_insert_post() um estado ou tipo de artigo em bruto | Alex Concha, equipa de segurança do WordPress |
Fontes: quem reportou, segundo WordPress.org, 6 de outubro de 2026; condições de exploração, segundo Patchstack, 6 de outubro de 2026.
Apenas uma das sete falhas funciona sem qualquer conta e sem intervenção da vítima: a fuga de comentários de artigos privados. A Patchstack explica o mecanismo: no feed de comentários de um único artigo, o WordPress começava por obter os comentários e só depois verificava se o visitante podia ver o artigo. A verificação escondia o artigo, mas não os comentários, e os feeds não devolvem 404, pelo que os comentários chegavam ao feed. Três das restantes seis exigem uma conta de Colaborador ou de Autor.
Quatro das sete notificações vêm de empresas que constroem modelos de IA ou dos seus parceiros. Isto ilustra bem a tese de Hubbard: hoje também a IA encontra falhas, e por cada uma alguém tem de pagar a triagem, a correção e a versão para cada ramo suportado. No anúncio lê-se que as correções são portadas para todos os ramos abrangidos por correções de segurança, atualmente até ao 4.7, e serão lançadas à medida que estiverem prontas.
Correções de segurança do WordPress 7.1.1 e 7.1.2
Segundo a Patchstack, duas semanas antes da 7.1.3 saiu a versão 7.1.2, que corrigiu uma vulnerabilidade (CVE-2026-87902). Permitia a um visitante sem sessão iniciada provocar a inclusão de um ficheiro local e, com a configuração de PHP adequada, levava à execução remota de código (Patchstack, 6 de outubro de 2026).
Antes, em setembro, a Patchstack descreveu também uma vulnerabilidade de execução remota de código corrigida na 7.1.1. Se o seu site está na 7.1.0, faltam-lhe as correções de três versões consecutivas.
O que é a Core Security Initiative do WordPress
A 28 de agosto de 2026, a equipa de segurança anunciou em make.wordpress.org a Core Security Initiative (Make WordPress Security, 28 de agosto de 2026). O anúncio associa o “substantial increase” no número de relatórios ao rápido desenvolvimento dos modelos de IA de fronteira. Descreve-o como um bom problema, que exige no entanto escalar a triagem, a verificação e a correção.
A iniciativa diz respeito ao núcleo do WordPress. Não abrange plugins nem temas. Os relatórios são recebidos pelo programa no HackerOne, e as vulnerabilidades do WordPress.com e das aplicações móveis seguem em separado, pelo programa da Automattic.
Como a Patchstack e a Wordfence filtram relatórios de vulnerabilidades em plugins gerados por IA
Os números do HackerOne cobrem apenas o núcleo. As falhas em plugins e temas passam por outros programas, e aí vê-se a mesma curva. Em março de 2026 o Wordfence Bug Bounty Program recebeu 1718 relatórios de vulnerabilidades, mais 59,4 % do que em fevereiro, de 321 investigadores ativos, e pagou 62 174 USD em recompensas nesse mês (Wordfence, relatório de março de 2026). O relatório não diz quantos desses envios foram escritos com ajuda de IA.
A Patchstack aponta a causa sem rodeios. A 29 de maio de 2026 Dave Jong, responsável de investigação de segurança da empresa, escreveu que desde a expansão da investigação assistida por IA, sobretudo em 2026, o programa recebe mais relatórios de baixo impacto que mal cumprem os critérios, mais duplicados (uma única vulnerabilidade acumulou mais de 20 envios duplicados de investigadores diferentes) e relatórios assentes em pressupostos errados gerados por IA (Patchstack, 29 de maio de 2026). Desde 1 de junho de 2026 a Patchstack:
- retirou do âmbito o papel de Colaborador (Contributor), pelo que a falha tem de ser acessível a um visitante, Subscritor, Cliente ou um papel baixo semelhante,
- associou condições a cada classe de vulnerabilidade, por exemplo o XSS tem de afetar todo o site ou ser refletido,
- limitou o fundo mensal de recompensas aos 5 melhores investigadores,
- suspende durante uma semana quem enviar pressupostos errados gerados por IA ou um relatório não testado no plugin ou tema real.
As diretrizes publicadas a 13 de outubro de 2026 exigem ainda uma prova de conceito em texto passo a passo, com pedidos HTTP em bruto e payloads exatos, e um componente com pelo menos 1000 instalações ativas (diretrizes do bug bounty da Patchstack).
Para o autor de um plugin este filtro conta mais do que o orçamento do núcleo. Um relatório que passa a triagem da plataforma acaba na mesma nas mãos do autor, que tem de o reproduzir e publicar uma correção, normalmente sem receber nada das recompensas.
Quem trata das vulnerabilidades de plugins e dos CVE no WordPress.org
O diretório de plugins tem o seu próprio caminho. O Plugin Handbook pede a quem reporta que contacte primeiro o programador e, só se isso falhar, escreva para [email protected], sem divulgar o problema publicamente. A equipa de plugins atua então sobre a própria ficha: a maioria dos plugins é fechada a novas transferências até o problema estar resolvido. A mesma página indica que a equipa não ajuda a pedir CVE por falta de recursos (Plugin Handbook, Reporting plugin security issues, última alteração a 2 de janeiro de 2026).
Por isso os identificadores CVE dos plugins WordPress vêm sobretudo de empresas de segurança registadas como CVE Numbering Authorities. A lista de parceiros do programa CVE atribui à Wordfence as vulnerabilidades em plugins, temas e núcleo descobertas pela sua equipa ou a ela reportadas, à WPScan o núcleo, os plugins e os temas do WordPress, e à Patchstack as vulnerabilidades encontradas pela sua equipa e pelos participantes do seu bug bounty (CVE Program, lista de parceiros).
Estas empresas pagam a triagem de plugins com receitas próprias e vendem proteção por cima. A Wordfence escreve que os utilizadores Premium, Care e Response recebem regras de firewall em tempo real e os da versão gratuita após 30 dias. É a segunda resposta a quem paga: nos plugins, o custo da triagem já está do lado dos fornecedores de segurança, e dois deles, a Wordfence e a Patchstack, estão na lista de Hubbard.
O que o Cyber Resilience Act da UE exige aos fabricantes de plugins WordPress
Desde 11 de setembro de 2026 parte deste custo é também uma obrigação legal na UE. O Regulamento de Ciber-Resiliência, Regulamento (UE) 2024/2847, aplica-se na íntegra a partir de 11 de dezembro de 2027, mas o artigo 71.º, n.º 2, antecipou o artigo 14.º sobre notificação para 11 de setembro de 2026 (Regulamento (UE) 2024/2847, EUR-Lex). Um fabricante que tome conhecimento de uma vulnerabilidade ativamente explorada no seu produto tem de a notificar à CSIRT designada como coordenadora e à ENISA através de uma plataforma única de notificação:
| Passo | Prazo segundo o artigo 14.º, n.º 2 |
|---|---|
| Alerta precoce | 24 horas após tomar conhecimento |
| Notificação da vulnerabilidade | 72 horas após tomar conhecimento |
| Relatório final | 14 dias depois de existir uma correção ou medida de mitigação |
O artigo 3.º, ponto 13, define o fabricante como quem desenvolve um produto e o comercializa com o seu próprio nome ou marca, a troco de pagamento, para monetização ou gratuitamente. Uma empresa que vende um plugin premium com a sua marca encaixa diretamente nessa redação. O artigo 13.º, n.º 6, acrescenta que o fabricante que detete uma vulnerabilidade num componente integrado, incluindo de código aberto, tem de a comunicar a quem mantém esse componente e partilhar a correção. Violar os artigos 13.º e 14.º pode custar até 15 milhões de euros ou 2,5 % do volume de negócios anual a nível mundial, consoante o que for mais elevado (artigo 64.º, n.º 2). As micro e pequenas empresas só ficam isentas de coimas por falharem o prazo de 24 horas do alerta precoce (artigo 64.º, n.º 10).
Os administradores de software de código aberto (open-source software stewards), pessoas coletivas que apoiam de forma sistemática software livre destinado a atividades comerciais, têm um regime mais leve: uma política de cibersegurança documentada (artigo 24.º) e nenhuma coima administrativa (artigo 64.º, n.º 10, alínea b)). O regulamento não diz quem paga a triagem desse administrador, que é a mesma pergunta que o e-mail de Hubbard coloca às empresas da sua lista.
O que o dono de um site WordPress deve fazer após a 7.1.3
O e-mail de Hubbard não muda nada no seu site de um dia para o outro. Os números do HackerOne e a lista da 7.1.3 traduzem-se, no entanto, em algumas coisas concretas:
- Instale a 7.1.3, se ainda não o fez. O anúncio recomenda a atualização imediata. Confirme em Painel de controlo, Atualizações, que o site tem de facto a 7.1.3, mesmo que tenha as atualizações automáticas ativas.
- Os ramos mais antigos recebem as correções mais tarde. Segundo a Patchstack, no dia do lançamento as correções chegaram aos ramos a partir da 6.6, e os ramos do 4.7 ao 6.5 ainda as aguardavam. Um site na 7.1 ficou protegido desde o primeiro dia.
- Limpe a cache depois de atualizar. A Patchstack avisa que a 7.1.3 não remove as incorporações oEmbed guardadas na base de dados, pelo que uma incorporação maliciosa do Imgur adicionada antes continua a ser apresentada até limpar a cache.
- Reveja as funções dos utilizadores. A Patchstack recomenda-o expressamente, porque três das sete falhas exigem uma conta de Colaborador ou de Autor. Convém remover, ou reduzir as permissões de, contas de antigos autores e de agências que já terminaram o trabalho há muito.
- O núcleo não é tudo. A Core Security Initiative não abrange os plugins. Se há muito que não revê os seus plugins, comece pela auditoria de plugins desatualizados e CVE conhecidos.
- Pode haver mais versões de segurança. Hubbard escreve que o ritmo dos relatórios continua a subir. Se só atualiza uma vez por trimestre, pode perder várias versões seguidas. Com uma manutenção contínua do site WordPress, as atualizações testam-se numa cópia e aplicam-se em dias, não em meses.
Se quer saber em que estado está agora o seu site, comece por uma auditoria de segurança WordPress.
Até quando as empresas devem comprometer financiamento
Hubbard ofereceu às empresas interessadas dados pormenorizados do programa e escreveu que quer ter o “primeiro grupo de contribuidores ao nosso lado neste trimestre” (tradução própria), ou seja, até ao fim de dezembro de 2026. Para já, nenhuma empresa anunciou publicamente um valor concreto. Acrescentarei uma atualização quando alguma o fizer.
Com que rapidez atualizar depois do WordPress 7.1.3 e quem paga os patches num contrato de manutenção Atualização 10.10.2026
A 10 de outubro de 2026 não encontrei nenhum compromisso público das empresas da lista, pelo que o quadro de financiamento acima mantém-se. O risco, esse, dá para precisar. A Patchstack avalia a 7.1.3 assim:
“Atualize assim que puder, mas isto não é uma emergência que obrigue a largar tudo.”
Patchstack, WordPress 7.1.3 security release, 6 de outubro de 2026, tradução própria
Uma das sete correções funciona sem conta e sem ação da vítima, e três foram reportadas pela Anthropic. Para o dono do site, o ritmo é: patch do núcleo em poucos dias, depois de testado numa cópia, não no trimestre seguinte.
O dinheiro que Hubbard pede cobre recompensas e triagem no núcleo. O trabalho no seu site (teste, instalação, revisão de plugins) é um custo à parte que o contrato tem de nomear. Pergunte a quem faz a manutenção do site três coisas: quantos dias depois de uma versão de segurança aplica a atualização do núcleo, se a testa primeiro em staging e se uma versão fora do ciclo cabe na mensalidade.
Última atualização: 13 de outubro de 2026.
