Em resumo: na segurança PHP do Drupal, após o PHP2Shell, trata-se sobretudo do servidor: a vulnerabilidade está no PHP, não no Drupal. Verifique o estado do PHP no relatório de estado e junto do operador, reinicie todos os processos PHP e controle depois settings.php, o diretório files e as permissões das funções.
Drupal e PHP2Shell: a situação
O Drupal é frequentemente usado em sites maiores, portais e entidades públicas, muitas vezes com muitos editores e interfaces. Segundo a equipa do PHP, as vulnerabilidades PHP CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso remotamente sem autenticação. O grau de manutenção do próprio Drupal é irrelevante para isso.
O Drupal tem uma equipa de segurança própria, que publica avisos sobre o núcleo e os módulos. O PHP2Shell não faz parte deles, porque não é uma vulnerabilidade do Drupal. Quem acompanha apenas os avisos do Drupal pode, por isso, ter deixado passar o alerta.
Em projetos Drupal maiores, a responsabilidade reparte-se muitas vezes por vários intervenientes: uma agência mantém o código, um centro de dados opera os servidores, a redação está na casa. Esclareça por escrito quem aplica a atualização do PHP, quem desencadeia o reinício e quem verifica se algo aconteceu antes. Em configurações com vários servidores web atrás de um balanceador de carga, cada servidor tem de ter o patch aplicado e estar reiniciado; caso contrário, parte dos pedidos fica no PHP antigo.
Segurança PHP no Drupal: verificar versão e estado do patch
Em Relatórios > Relatório de estado, o Drupal mostra a versão do PHP com que o site corre, juntamente com avisos sobre a configuração. Na linha de comandos, drush status fornece a versão do PHP da CLI, com que correm também as tarefas cron e os deployments. Ambas têm de ter o patch aplicado.
As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As distribuições e os fornecedores de alojamento incorporam por vezes as correções como backport; nesse caso, o número mantém-se; o que conta é o estado do pacote confirmado. Quais as versões do PHP que a sua versão do Drupal suporta, verifique-o nos requisitos de sistema em drupal.org. Depois da atualização faz parte o reinício, descrito em Reiniciar o PHP-FPM e todos os workers.
Pastas e ficheiros que contam
| Local | Conteúdo | Ponto de verificação |
|---|---|---|
sites/default/settings.php |
Base de dados, hash salt, trusted_host_patterns |
Data de alteração, includes inseridos |
sites/default/files/ |
Uploads públicos, imagens geradas, CSS e JS | Sem ficheiros PHP, .htaccess presente |
| Diretório de ficheiros privado | Uploads protegidos, muitas vezes fora da raiz de documentos | Direitos de acesso |
modules/contrib/, modules/custom/ |
Módulos do drupal.org e desenvolvimentos próprios | Módulos alterados ou desconhecidos |
themes/ |
Temas com templates Twig | JavaScript alheio |
vendor/ |
Dependências do Composer | composer audit |
O Drupal cria no diretório files um .htaccess que impede a execução de PHP. No Apache funciona; no Nginx, não. Aí é necessária uma regra própria:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Verificações inofensivas com ferramentas do sistema e Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Compare o estado do código no servidor com o seu repositório Git. Em projetos Drupal com Composer, esse é o caminho mais rápido para encontrar ficheiros alheios ou alterados, pois qualquer desvio tem de poder ser explicado.
Funções, permissões e módulos como risco
O início de sessão fica em /user/login, a área de gestão em /admin. No Drupal, a segurança não é decidida apenas pelas contas de administrador, mas por permissões individuais. Direitos como gerir módulos, utilizadores, permissões ou formatos de texto com HTML completo são, na prática, direitos de administrador. Verifique em Pessoas e Permissões que direitos têm as funções e quem pertence a essas funções.
Os módulos contrib ampliam muito o Drupal, mas trazem código próprio. Módulos sem manutenção ativa e desenvolvimentos próprios antigos são muitas vezes a razão pela qual uma atualização do PHP é adiada. Mais sobre dependências em Verificar vulnerabilidades nas dependências do Composer.
O que uma atualização do Drupal faz e o que não faz
Uma atualização do núcleo ou de um módulo corrige falhas nesse código e pode permitir versões mais recentes do PHP. Não aplica patch ao PHP, não remove ficheiros alheios de sites/default/files, não repõe permissões e não elimina contas criadas às escondidas. Também a cache pode continuar a entregar conteúdos manipulados até ser esvaziada. Perante uma suspeita, devem renovar-se o hash salt e o acesso à base de dados.
Em instalações multisite, vários sites partilham o mesmo código, mas têm, em sites/, o seu próprio settings.php e o seu próprio diretório files. Verifique então cada site individualmente. Uma descoberta num site afeta, devido ao código partilhado, normalmente todos os outros também.
Como ajuda concretamente a PHP SOS?
- Verificamos o PHP web e o PHP CLI do seu servidor Drupal e fazemos confirmar o patch e o reinício.
- Guardamos registos e dados e comparamos o estado do código com o seu repositório ou com os pacotes originais.
- Controlamos
settings.php, o diretóriofiles, as regras do servidor, as funções e as permissões. - Se pretender, assumimos a manutenção contínua no contrato de manutenção de segurança, para que as atualizações do PHP e do Drupal não voltem a divergir.
Perguntas frequentes
Uma atualização de segurança do Drupal ajuda contra o PHP2Shell?
Não. As atualizações do Drupal corrigem falhas no núcleo e nos módulos do Drupal. O PHP2Shell está no PHP do servidor e exige uma atualização do PHP ou um backport confirmado, bem como o reinício de todos os processos PHP.
Onde mostra o Drupal a versão do PHP?
No relatório de estado, em Relatórios. Com o Drush, drush status mostra a versão do PHP da linha de comandos. As duas indicações podem diferir e, em nenhuma delas, se reconhece com segurança um backport.
O .htaccess na pasta files protege também no Nginx?
Não. O .htaccess criado pelo Drupal só é avaliado pelo Apache. No Nginx precisa de uma regra própria na configuração do servidor que bloqueie ficheiros PHP no diretório files.
O que significa trusted_host_patterns?
A definição em settings.php determina sob que nomes de anfitrião o Drupal responde. Protege contra ataques através de indicações de anfitrião manipuladas e deve constar de qualquer instalação em produção.