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 “Monday evening UTC” no texto de quinta-feira, 8 de outubro. A tese principal: a IA baixou o custo de encontrar falhas.
“AI had collapsed the cost of finding, reporting, and exploiting vulnerabilities”
Mary Hubbard, citada pelo The Repository, 8 de outubro de 2026
Segundo ela, em 90 dias o programa recebeu quase 2000 relatórios, mais do que alguma vez, “and the pace is still climbing”. 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.
“Nearly half the program’s lifetime payouts happened in a single quarter, and the curve only goes one direction.”
Mary Hubbard, citada pelo The Repository, 8 de outubro de 2026
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: “The economics are what’s broken, not the program”.
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, “unfortunately without much traction”.
- 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, “this process needs to be reformed”.
GoDaddy, Newfold Digital e Wordfence não responderam até à publicação do texto.
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.
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 “first group of contributors standing with us this quarter”, 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.
Última atualização: 9 de outubro de 2026.
