Em resumo: Uma atualização do WordPress não ajuda contra a vulnerabilidade PHP2Shell, porque o erro não está no WordPress, mas no PHP, o software do servidor que executa o WordPress. Segundo o Dr. Web, o WordPress.org também não planeia, por isso, nenhuma atualização própria. Só uma atualização do PHP no servidor, com reinício de todos os processos PHP, pode proteger. Em regra, é o seu fornecedor de alojamento ou operador do servidor que a aplica.
O ponto de partida: “Mas nós atualizámos tudo”
Depois das primeiras manchetes sobre o PHP2Shell, muitos operadores fizeram o mais óbvio: abrir o painel do WordPress, clicar em “Atualizar agora”, e atualizar também plugins e temas. Depois está tudo verde, e a sensação diz: resolvido.
Nesta vulnerabilidade, a sensação engana. Isso não se deve ao WordPress, mas ao sítio onde o erro está. Também a Cloudflare, no seu comunicado, chama a atenção para o facto de uma atualização do código da aplicação ou dos plugins não corrigir as vulnerabilidades.
Atualização do WordPress e vulnerabilidade PHP: o modelo de camadas
Um site WordPress é composto por várias camadas que assentam umas nas outras. Cada camada tem as suas próprias atualizações e muitas vezes os seus próprios responsáveis:
| Camada | Exemplo | Quem atualiza normalmente | Afetada pelo PHP2Shell? |
|---|---|---|---|
| Sistema operativo | Debian, Ubuntu, AlmaLinux | fornecedor de alojamento ou administrador do servidor | não, mas fornece muitas vezes o pacote PHP |
| Servidor web | Apache, Nginx, LiteSpeed | fornecedor de alojamento ou administrador do servidor | o modo de operação influencia o risco |
| Tempo de execução PHP | PHP-FPM, mod_php | fornecedor de alojamento ou administrador do servidor | sim, é aqui que está a vulnerabilidade |
| Núcleo do WordPress | WordPress | operador ou agência | não |
| Plugins e temas | WooCommerce, page builder | operador ou agência | não |
O botão de atualização do painel só chega às duas linhas de baixo. O tempo de execução PHP fica por baixo e é invisível para o WordPress. Como outros sistemas assentam no PHP é descrito no artigo CMS e lojas em PHP.
Porque é que o WordPress não pode fechar a vulnerabilidade
Poderia pensar-se que o WordPress podia simplesmente “programar à volta”. No PHP2Shell isso não funciona por duas razões.
Em primeiro lugar, ambos os erros estão na forma como o PHP processa pedidos e arruma depois. Isso acontece independentemente do programa que corre no PHP. Em segundo lugar, a equipa do PHP demonstrou para o Apache com mod_php um exploit que atua antes de sequer ser executado código da aplicação. O WordPress, os seus plugins e qualquer plugin de segurança nem chegam, então, a entrar em jogo.
Pela mesma razão, também não ajuda nenhum “plugin de reforço” que altere definições através de ini_set(). O php.net desaconselha expressamente aplicar medidas provisórias por esse caminho.
E no WordPress gerido?
Nas ofertas de WordPress gerido, o fornecedor trata muitas vezes não só das atualizações do WordPress, mas também do servidor que está por baixo. Para o PHP2Shell isso é uma vantagem, mas não um automatismo. Pergunte concretamente se a atualização do PHP foi aplicada e se todos os processos PHP foram reiniciados. A afirmação “Mantemos o seu WordPress atualizado” não responde a esta pergunta.
Muitos sites, uma instalação PHP
As agências e as empresas com vários sites devem conhecer uma particularidade: num servidor, muitas instalações WordPress partilham frequentemente a mesma versão do PHP. Se esta estiver sem patch, todas estão afetadas, independentemente de quão bem cada site é mantido. Inversamente, uma atualização do PHP protege todas as instalações de uma só vez, desde que depois sejam reiniciados todos os processos PHP correspondentes. Quem opera várias versões do PHP em paralelo tem de atualizar cada uma individualmente.
Um painel do WordPress todo verde não diz nada sobre o PHP2Shell. O decisivo é o nível de patch do PHP no servidor e o reinício de todos os processos PHP.
Ler corretamente a versão do PHP no WordPress
O WordPress mostra a versão do PHP: no painel, em Ferramentas, Saúde do site, no separador Informações, na secção Servidor. É uma boa primeira indicação, mas não é uma prova.
Se aí estiver um ramo como 8.1 ou anterior, é um sinal de alerta claro, porque para esses já não há atualizações oficiais. Se aí estiver 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, está instalada a versão corrigida. Se aí estiver um número mais antigo de um ramo suportado, pode ainda assim ter sido aplicado um backport. As distribuições e os fornecedores de alojamento muitas vezes não alteram o número. Só a confirmação do fornecedor ou uma consulta ao registo de alterações do pacote trazem clareza. Como se faz está em Verificar versão do PHP e nível de patch.
O que os operadores de WordPress devem fazer em vez disso
- Perguntar ao fornecedor de alojamento ou operador do servidor: o PHP tem patch, desde quando, e todos os processos PHP foram reiniciados? Resposta por escrito.
- Verificar o ramo do PHP: se o site corre em 8.1 ou anterior, planear a mudança para um ramo suportado. Que versão a sua versão do WordPress suporta consta dos requisitos de sistema em wordpress.org. A mudança no menu de cliente é descrita em Alterar a versão do PHP na área de cliente do alojamento.
- Procurar vestígios: novos ficheiros PHP em
wp-content/uploads, contas de administrador desconhecidas, entradas estranhas emmu-plugins. Os esconderijos típicos são descritos na página WordPress e PHP2Shell. - Manter o WordPress atualizado, ainda assim: núcleo, plugins e temas fecham outras vulnerabilidades. Continua a ser obrigatório, só que é outra obrigação.
- Esclarecer a responsabilidade: se uma agência trata do site, registar se também é responsável pelo PHP ou só pelo WordPress.
Precisamente o último ponto origina muitas vezes lacunas. A agência cuida do WordPress, o fornecedor de alojamento do servidor, e cada um acredita que o outro tem o PHP2Shell debaixo de olho.
Como ajuda concretamente a PHP SOS?
- Esclarecer as camadas: Apuramos quem, no seu site WordPress, é responsável por cada camada.
- Atualizar o PHP: Em servidores próprios ou geridos, aplicamos a atualização do PHP e reiniciamos todos os processos.
- Verificar o WordPress: Procuramos vestígios de um ataque em ficheiros, base de dados e contas.
- Comprovativo: Recebe o nível de patch por escrito, também para entregar à agência ou a clientes.
O procedimento é descrito no serviço de patches PHP.
Conclusão
A atualização do WordPress é boa manutenção, mas contra o PHP2Shell é a camada errada. A vulnerabilidade está um andar abaixo, no PHP do servidor. Quem o compreende faz a pergunta certa à entidade certa: o PHP tem patch, foi reiniciado e está comprovado?
Perguntas frequentes
O WordPress lança uma atualização de segurança contra o PHP2Shell?
Segundo o Dr. Web, o WordPress.org não planeia nenhuma atualização contra o PHP2Shell, porque a vulnerabilidade está no interpretador PHP do servidor. Só uma atualização do PHP pelo fornecedor de alojamento ou pelo operador do servidor resolve.
Onde vejo a versão do PHP no WordPress?
No painel, em Ferramentas, Saúde do site, no separador Informações, na secção Servidor. O número apresentado não diz, porém, com segurança se o patch foi aplicado, porque os fornecedores de alojamento incorporam muitas vezes correções como backport sem novo número de versão.
Um plugin de segurança protege contra o PHP2Shell?
Só de forma muito limitada. Um plugin corre ele próprio em PHP e só fica ativo quando o WordPress é carregado. No Apache com mod_php foi demonstrado, segundo a equipa do PHP, um exploit antes de sequer ser executado código da aplicação. Aí um plugin não consegue intervir.
Devo atualizar o WordPress na mesma?
Sim. As versões atuais do WordPress, dos temas e dos plugins fecham outras vulnerabilidades e fazem parte de uma boa manutenção. Apenas não resolvem o problema do PHP2Shell.