# Vulnerabilidade PHP2Shell no WordPress: o que os operadores têm de fazer

> O PHP2Shell afeta o WordPress através do PHP, não do núcleo. Verifique versão do PHP, uploads, mu-plugins e administradores e proteja o seu site.

Fonte: https://phpsos.de/pt/plattformen/wordpress/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** a vulnerabilidade PHP de que agora se fala não está no WordPress, mas no PHP do servidor que lhe serve de base. Por isso, uma atualização do WordPress não corrige o PHP2Shell. O que conta é o estado do patch do PHP, o reinício de todos os processos PHP e a verificação dos esconderijos habituais, como `wp-content/uploads` e `mu-plugins`.

## Porque é que uma atualização do WordPress não resolve o PHP2Shell

O WordPress é uma aplicação escrita em PHP. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 situam-se um nível abaixo, no próprio interpretador PHP. Segundo a equipa do PHP, permitem a execução remota de código malicioso sem autenticação. Com o Apache e mod_php foi demonstrado um exploit antes de qualquer código do WordPress ser executado.

Um site com o núcleo atualizado, plugins atualizados e palavras-passe fortes pode, portanto, continuar vulnerável se o PHP por baixo for antigo. Inversamente, um PHP com patch não prova que nada tenha acontecido antes. Explicamos o contexto em [O que é o PHP2Shell?](https://phpsos.de/pt/php2shell/was-ist-php2shell/).

| Nível | Quem atualiza | Corrige o PHP2Shell? |
|---|---|---|
| Núcleo do WordPress | Você ou a sua agência | Não |
| Plugins e temas | Você ou a sua agência | Não |
| PHP no servidor | Fornecedor de alojamento ou administrador do servidor | Sim, juntamente com o reinício de todos os processos PHP |

## Vulnerabilidade PHP no WordPress: verificar a versão do PHP

No painel de controlo, em **Ferramentas > Estado do site > Informações**, na secção «Servidor», encontra a versão do PHP com que o seu site realmente corre. Isto é mais fiável do que `php -v` na linha de comandos, porque a linha de comandos usa muitas vezes uma instalação PHP diferente da do servidor web.

Ainda assim, o número apresentado não basta. As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Muitos fornecedores de alojamento, porém, incorporam as correções como backport; nesse caso continua a aparecer um número mais antigo, embora o patch esteja aplicado. Como apurar o estado real está em [Verificar corretamente a versão e o estado do patch do PHP](https://phpsos.de/pt/php2shell/php-version-pruefen/). Quais as versões do PHP que a sua versão do WordPress suporta, verifique-o nos requisitos de sistema em wordpress.org.

## Onde o código malicioso gosta de se esconder no WordPress

Depois de um ataque bem-sucedido, os atacantes costumam deixar uma backdoor para poderem voltar mesmo depois do patch. O WordPress tem locais conhecidos para isso:

- **wp-content/uploads/**: destinada a imagens e PDF, não a ficheiros PHP.
- **wp-content/mu-plugins/**: os plugins «must-use» carregam automaticamente e não podem ser desativados no painel de controlo.
- **wp-config.php**: contém o acesso à base de dados e as chaves de segurança; uma linha inserida passa aqui quase despercebida.
- **.htaccess** na pasta principal e em subpastas: redirecionamentos apenas para motores de busca ou a execução de extensões de ficheiro invulgares.
- **Temas**, sobretudo `functions.php`, bem como plugins desativados e esquecidos.
- **Base de dados**: novos administradores em `wp_users`, JavaScript estranho em `wp_options` ou em artigos.

Primeiras verificações inofensivas com WP-CLI e ferramentas do sistema:

```bash
# Comparar os ficheiros do núcleo com as somas de verificação oficiais
wp core verify-checksums
# Verificar os plugins do diretório em wordpress.org
wp plugin verify-checksums --all
# Listar os ficheiros PHP na pasta de uploads
find wp-content/uploads -type f -name "*.php"
# Mostrar todos os administradores
wp user list --role=administrator
```

Um resultado é motivo para uma análise rigorosa, ainda não uma prova. Os plugins comerciais não podem ser verificados desta forma. Encontra mais pormenores no guia [Encontrar backdoors no WordPress](https://phpsos.de/pt/ratgeber/backdoor-wordpress-finden/).

> **Importante:**
> Não apague ficheiros suspeitos precipitadamente. Guarde primeiro os ficheiros, a base de dados e os registos do servidor a partir de 20/10/2026. Sem estes vestígios não será possível esclarecer mais tarde se houve fuga de dados.

## Plugins, temas e acessos de administrador como risco adicional

O PHP2Shell não precisa de uma falha num plugin. No dia a dia, porém, os plugins e os temas continuam a ser a porta de entrada mais frequente nos sites WordPress. Cada plugin traz código próprio, funções de upload próprias e ciclos de atualização próprios. Os plugins que não usa devem ser eliminados e não apenas desativados, pois os ficheiros desativados continuam no servidor.

Para `wp-login.php` e `wp-admin` aplica-se: poucos administradores, contas pessoais em vez de acessos partilhados e autenticação de dois fatores. Se não precisar do XML-RPC, pode bloqueá-lo. Perante uma suspeita, devem renovar-se todas as palavras-passe e as chaves de segurança em `wp-config.php`. O editor de ficheiros do painel de controlo também se desativa aí:

```php
define( 'DISALLOW_FILE_EDIT', true );
```

## O que deve fazer agora como operador de WordPress

1. Pedir ao fornecedor de alojamento que confirme por escrito o estado do patch do PHP e o reinício de todos os processos PHP.
2. Pedir que sejam conservados os registos do servidor a partir de 20/10/2026.
3. Efetuar as verificações acima ou mandá-las efetuar.
4. Atualizar o WordPress, os plugins e os temas. Isto é correto, mas não substitui o passo 1.
5. Em caso de anomalias, não continuar simplesmente a operar o site, mas mandá-lo limpar.

Uma atualização da plataforma pode corrigir falhas conhecidas no WordPress e nos plugins. Não consegue reparar o PHP nem remover ficheiros introduzidos que não pertencem ao núcleo.

## Como ajuda concretamente a PHP SOS?

- Esclarecemos consigo ou com o seu fornecedor de alojamento o estado real do PHP do seu site WordPress, incluindo backports e reinício.
- Guardamos registos, ficheiros e base de dados antes de alterar o que quer que seja.
- Verificamos no núcleo, nos plugins, nos uploads, nos mu-plugins, no `.htaccess` e nas contas de utilizador se existem backdoors.
- Em caso de descobertas, a nossa [remoção de malware](https://phpsos.de/pt/leistungen/malware-entfernung/) assegura a limpeza até o incidente estar concluído e documentado; sem descobertas, reforçamos a instalação no âmbito da [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/).


## Perguntas frequentes

**Tenho de atualizar o WordPress por causa do PHP2Shell?**  
Um WordPress atualizado é sempre aconselhável, mas não corrige o PHP2Shell. A falha está no interpretador PHP do servidor. Para isso é preciso uma atualização do PHP ou um backport confirmado pelo seu fornecedor de alojamento, e o reinício de todos os processos PHP.

**Um plugin de segurança protege contra o PHP2Shell?**  
Só de forma muito limitada. Um plugin é ele próprio código PHP que corre dentro do WordPress. Com o mod_php foi demonstrado um exploit antes de o código da aplicação sequer arrancar; um plugin pode, por isso, nem chegar a aperceber-se do ataque.

**Porque é que o WordPress ainda mostra uma versão antiga do PHP, apesar de o fornecedor ter aplicado o patch?**  
Muitos fornecedores de alojamento e distribuições Linux incorporam as correções como backport na versão existente. O número de versão mantém-se então igual. Peça ao fornecedor que lhe confirme por escrito o estado do patch.

**Pode existir um ficheiro PHP em wp-content/uploads?**  
Normalmente não. A pasta de uploads destina-se a ficheiros multimédia. Um ficheiro PHP aí é um sinal de alerta claro e deve ser guardado e analisado por especialistas antes de ser apagado.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [WordPress.org](https://wordpress.org/)
- [BSI](https://www.bsi.bund.de/)
