105. Atualização urgente para as versões 6.8, 6.9 e 7.0

Foi publicada uma versão de segurança para as versões 6.8, 6.9, 7.0 e 7.1-beta, que corrige dois problemas críticos de segurança no núcleo do WordPress.

Transcrição do programa

Olá, sou José Freitas e estás a ouvir o WPpodcast, com as notícias semanais da comunidade WordPress.

Neste episódio, encontras a informação relativa ao período de 13 a 19 de julho de 2026.

A principal notícia desta semana está relacionada com segurança e é grave. O WordPress lançou a versão 7.0.2, uma versão de emergência que corrige duas vulnerabilidades: uma crítica e outra de gravidade elevada.

A vulnerabilidade crítica, já conhecida na comunidade como «wp2shell» e catalogada como CVE-2026-63030, permite que um atacante não autenticado execute código através do endpoint de ações em lote da REST API, sem precisar de uma conta ou da interação de um utilizador, numa instalação padrão e sem plugins. Esta vulnerabilidade pode ainda ser combinada com uma falha de injeção SQL identificada como CVE-2026-60137, formando uma cadeia completa de exploração.

Devido à gravidade da situação, a equipa do WordPress.org ativou atualizações forçadas através do sistema de atualizações automáticas para os sites afetados, pelo que muitos sites já terão sido atualizados automaticamente.

Ainda assim, vale a pena confirmar manualmente: acede ao painel, entra em “Atualizações” e força a opção “Atualizar agora”, caso seja necessário. As versões afetadas também receberam correções retroativas: a versão 6.9 passa para a 6.9.5, corrigindo ambas as falhas, e a versão 6.8 passa para a 6.8.6, corrigindo apenas o problema de injeção SQL. A versão beta do WordPress 7.1 também foi atualizada para a beta 2, incluindo as duas correções. As versões anteriores à 6.8 não são afetadas.

Até ao momento, não existem exploits públicos confirmados nem provas de exploração ativa. No entanto, vários investigadores alertam que, sendo o WordPress um projeto de código aberto, será apenas uma questão de tempo até surgir uma prova de conceito pública.

WordPress 7.1 Beta 1

Temos também o WordPress 7.1 Beta 1, cuja versão final está prevista para 19 de agosto. É uma versão repleta de funcionalidades que finalmente introduz no núcleo um conjunto significativo de recursos que já estavam a ser desenvolvidos há algum tempo no plugin Gutenberg.

As Notas tornam-se uma ferramenta de colaboração muito mais completa:

• passam a suportar formatação de texto em linha,
• menções com @,
• vários tópicos independentes no mesmo bloco
• e notas associadas a uma seleção específica de texto, em vez de estarem ligadas ao bloco inteiro.

Ao nível do design, chega finalmente ao editor um verdadeiro sistema de estilos responsivos. Será possível, por exemplo:

• definir o aspeto de um bloco num tablet ou telemóvel sem escrever uma única linha de CSS,
• personalizar breakpoints através do theme.json
• e aplicar estilos a estados interativos, como hover ou focus, tanto globalmente como em cada instância individual de um bloco.

A experiência de gestão de conteúdos multimédia também dá um salto significativo:

• o processamento de imagens passa a ser feito no navegador, com suporte alargado para HEIC, AVIF e UltraHDR, bem como conversão de GIF para vídeo;
• os carregamentos tornam-se mais resistentes, com novas tentativas automáticas em caso de falha, e surge uma nova janela de edição de imagens que reúne num único local o recorte, a rotação e os metadados;
• as galerias também se tornam mais inteligentes, podendo obter automaticamente as imagens que já estão associadas à publicação.

Quanto aos novos blocos, chegam:

• o bloco Lista de reprodução, com leitor de áudio e visualização da forma de onda,
• e o bloco Separadores, que permite organizar conteúdo em diferentes separadores. Tudo isto sem necessidade de plugins de terceiros.

A outra grande alteração desta versão está relacionada com a navegação: a barra de ferramentas de administração passa a estar sempre disponível, tanto no editor de publicações como no Editor do site. Até agora, esta barra desaparecia no Editor do site.

O ícone com o logótipo do WordPress, que funcionava de forma pouco intuitiva como botão para voltar atrás, é substituído por um botão específico em forma de seta. O logótipo passa a abrir sempre a página “Sobre” e o ícone do site, quando existe, abre o menu do site. Caso desenvolvas plugins que adicionem elementos a esta barra, convém confirmar que continuam a funcionar corretamente no Editor do site, uma vez que este modo persistente não existia anteriormente nesse contexto.

Para quem desenvolve blocos

Para quem desenvolve blocos, esta é uma versão que merece especial atenção. A partir do WordPress 7.1, a área de edição do editor de publicações será sempre apresentada dentro de um iframe, independentemente do tema utilizado ou da apiVersion declarada nos blocos.

Até agora, bastava existir na publicação um único bloco ativo com apiVersion 2 ou inferior para que todo o editor deixasse de ser apresentado dentro do iframe. Esse comportamento desaparece por completo na versão 7.1.

A vantagem é evidente: os estilos da área de administração deixam de interferir com o conteúdo e unidades como vw ou vh, bem como as media queries, passam finalmente a ser calculadas com base na própria área de edição e não na página de administração. Desta forma, as pré-visualizações para tablet e telemóvel passam a comportar-se verdadeiramente como no frontend.

Testes pede ajuda para testes

Como acontece em todos os ciclos, a equipa de Testes está a pedir ajuda ativa. Não precisas de ser profissional de garantia de qualidade, basta utilizares o WordPress como farias normalmente num ambiente de testes e comunicares tudo o que não funcionar como esperado. Existem guias passo a passo para testar cada uma das novas funcionalidades: Notas, estilos responsivos, estados interativos, barra de ferramentas persistente, janela de edição de conteúdos multimédia e galerias dinâmicas.

Como configurar a página de manutenção

O Blogue para programadores publicou um tutorial para configurar uma página de manutenção adaptada à identidade visual de cada site, em vez da habitual e pouco apelativa mensagem “temporariamente indisponível” apresentada pelo WordPress durante as atualizações.

O aspeto mais interessante desta técnica é a forma como distribui o trabalho: o programador adiciona uma única vez um hook ao ficheiro de funções do plugin personalizado e, a partir daí, toda a gestão da página de manutenção, tanto o design como a ativação, é feita através do Editor do site, sem voltar a editar código ou ficheiros.

O hook procura na base de dados um modelo com o nome exato Maintenance e, caso o encontre, apresenta-o a qualquer visitante que não tenha sessão iniciada. Quem tiver sessão iniciada continua a ver o site normalmente, o que é útil para rever as alterações durante a própria atualização. Existe também uma variante um pouco mais elaborada, que adiciona cabeçalhos destinados aos motores de pesquisa: um código de estado 503, “serviço indisponível”, um cabeçalho Retry-After que sugere uma nova tentativa dentro de uma hora e cabeçalhos que impedem a utilização de cache.

Desta forma, o site volta a ser apresentado sem problemas de cache assim que o modo de manutenção é desativado. Esta opção é particularmente recomendada para sites que recebem tráfego importante proveniente de motores de pesquisa ou quando os períodos de manutenção são prolongados.

Com o hook instalado, criar o modelo é tão simples como aceder a Aparência → Editor → Modelos, adicionar um novo modelo com o nome “Maintenance” e construí-lo como qualquer outro modelo.

Playground pede testes de interface

A equipa do Playground lançou um convite para testar a nova interface do WordPress Playground antes do lançamento oficial e procura feedback tanto sobre a versão para computador como para dispositivos móveis. Não precisas de testar tudo. São propostos quatro blocos de testes independentes, desde a criação e gestão de playgrounds, passando pela galeria de blueprints, até à manipulação de ficheiros, bases de dados e registos, ou ao teste das funcionalidades de importação e exportação de sites, incluindo a exportação para o GitHub.

O mais interessante é que foi disponibilizado um ambiente público de testes, acessível sem necessidade de instalar nada. A equipa pede que prestes atenção a aspetos específicos: se os textos e botões são compreensíveis, se o comportamento corresponde ao esperado, se existem problemas de apresentação e o que poderia ser melhorado.

Community Agents

A equipa da Comunidade apresentou os Community Agents, uma plataforma de assistentes de IA desenvolvidos para reduzir o trabalho associado a tarefas repetitivas, como rever candidaturas de organizadores de eventos, verificar orçamentos de WordCamps e auditar sites para identificar problemas relacionados com a licença GPL ou com a utilização da marca WordPress.

O projeto assenta em dois princípios. O primeiro é a presença de uma pessoa no processo de decisão, o chamado human in the loop. Isto significa que o agente apresenta propostas, mas nunca aprova nada automaticamente. O segundo princípio é o respeito pela privacidade, uma vez que os agentes trabalham apenas com informação pública, como perfis do WordPress.org ou links, sem solicitar dados pessoais, como endereços de email ou moradas.

Adson para o CampTix

Foi apresentado um novo addon para o CampTix, o sistema utilizado para gerir eventos da comunidade, com o objetivo de resolver um problema clássico dos WordCamps: a gestão de atividades com capacidade limitada, como o Contributor Day, o jantar social ou os workshops.

Até agora, estas atividades eram geridas através de formulários paralelos, folhas de cálculo cruzadas manualmente ou simplesmente recorrendo ao bom senso dos participantes. O addon, atualmente conhecido informalmente como “activity tickets”, permite que os organizadores criem estas atividades como bilhetes CampTix normais, com preço zero, e que os identifiquem como bilhetes de atividade no próprio painel de definições.

O addon está concluído e foi testado localmente, com mais de cinquenta testes automatizados e um teste completo realizado num site real de um WordCamp. No entanto, ainda não foi submetido oficialmente. Antes disso, a equipa está a pedir feedback à comunidade, especialmente a quem já tenha organizado um Contributor Day ou outra atividade com capacidade limitada.

Porto WordPress Meetup aborda acessibilidade

A edição deste mês do Porto WordPress Meetup vai abordar um tema fundamental: a acessibilidade Web e no email já não é opcional.

O Ato Europeu da Acessibilidade entrou em vigor há cerca de um ano, mas 2026 é o primeiro ano em que os reguladores o estão realmente a aplicar, com multas e processos judiciais a surgir por toda a Europa e é provável que o resto do mundo siga o mesmo caminho.

Nesta apresentação, iremos além dos chavões legais e analisar o que a acessibilidade digital significa na prática: como construir e auditar websites acessíveis, e por que razão os emails quebram quase todas as regras sem que quase ninguém queira saber disso.

A apresentação será feita por Fabio Biocchetti, que trabalha na web há mais de 10 anos, algures entre a engenharia de front-end e o marketing, nunca muito longe do desenvolvimento pixel-perfect, de emails e de tudo o que é direcionado ao cliente.

A apresentação será em inglês.

O Porto WordPress Meetup de Julho será no dia 30, às 19h00, na Kaksi Media, Rua Conde de Alto Mearim, 734, sala 2, Matosinhos, bem perto do centro da cidade.

A entrada é gratuita, mas os lugares são limitados, por isso, é essencial registar a presença na página do evento no meetup .com.

Por fim, este podcast é distribuído sob uma licença Creative Commons, como versão derivada do podcast em espanhol. Podes encontrar todos os links para mais informações, bem como o podcast noutros idiomas, em WPpodcast .org.

Obrigado por ouvires e até ao próximo episódio.