En resumen: en la seguridad de PHP en Drupal, tras PHP2Shell se trata sobre todo del servidor: la vulnerabilidad está en PHP, no en Drupal. Compruebe el estado de PHP en el informe de estado y con el operador, reinicie todos los procesos de PHP y, después, controle settings.php, el directorio files y los permisos de los roles.
Drupal y PHP2Shell: la situación
Drupal se utiliza con frecuencia para sitios web grandes, portales y entidades públicas, a menudo con muchos redactores e interfaces. Según el equipo de PHP, las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso de forma remota y sin autenticación. Lo bien mantenido que esté Drupal no influye en ello.
Drupal tiene su propio equipo de seguridad, que publica avisos sobre el núcleo y los módulos. PHP2Shell no figura entre ellos, porque no es una vulnerabilidad de Drupal. Quien solo sigue los avisos de Drupal puede, por tanto, haber pasado por alto la noticia.
En los proyectos Drupal más grandes, la responsabilidad suele repartirse entre varios actores: una agencia mantiene el código, un centro de datos opera los servidores y la redacción está en la propia casa. Aclare por escrito quién aplica la actualización de PHP, quién provoca el reinicio y quién comprueba si antes ha pasado algo. En configuraciones con varios servidores web detrás de un balanceador de carga, cada servidor debe estar parcheado y reiniciado; de lo contrario, una parte de las peticiones sigue en el PHP antiguo.
Seguridad de PHP en Drupal: comprobar la versión y el nivel de parcheo
En Informes > Informe de estado, Drupal muestra la versión de PHP con la que se ejecuta el sitio web, junto con advertencias sobre la configuración. En la línea de comandos, drush status proporciona la versión del PHP de CLI, con el que también se ejecutan los cron jobs y los despliegues. Ambos deben estar parcheados.
Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Las distribuciones y los proveedores de hosting aplican a veces las correcciones como backport; entonces el número no cambia, y lo que cuenta es el estado de los paquetes confirmado. Qué versiones de PHP admite su versión de Drupal puede consultarlo, según los requisitos del sistema, en drupal.org. Tras la actualización hay que reiniciar, como se describe en Reiniciar PHP-FPM y todos los workers.
Directorios y archivos que cuentan
| Lugar | Contenido | Punto de control |
|---|---|---|
sites/default/settings.php |
Base de datos, hash salt, trusted_host_patterns |
Fecha de modificación, includes añadidos |
sites/default/files/ |
Subidas públicas, imágenes generadas, CSS y JS | Sin archivos PHP, .htaccess presente |
| Directorio de archivos privados | Subidas protegidas, a menudo fuera de la raíz de documentos | Permisos de acceso |
modules/contrib/, modules/custom/ |
Módulos de drupal.org y desarrollos propios | Módulos modificados o desconocidos |
themes/ |
Temas con plantillas Twig | JavaScript ajeno |
vendor/ |
Dependencias de Composer | composer audit |
Drupal crea en el directorio files un .htaccess que impide la ejecución de PHP. Con Apache funciona; con Nginx, no. Allí hace falta una regla propia:
location ~* ^/sites/.+/files/.+\.php$ {
deny all;
}
Comprobaciones inofensivas con los recursos del sistema y Drush:
find sites/*/files -type f -name "*.php"
drush pm:list --status=enabled --type=module
composer audit
Compare el estado del código en el servidor con su repositorio Git. En los proyectos Drupal con Composer es el camino más rápido para encontrar archivos ajenos o modificados, porque cualquier diferencia debe poder explicarse.
Roles, permisos y módulos como riesgo
El inicio de sesión está en /user/login y el área de gestión en /admin. En Drupal, la seguridad no depende solo de las cuentas de administrador, sino de permisos individuales. Permisos como administrar módulos, usuarios, permisos o formatos de texto con HTML completo son en la práctica derechos de administrador. Revise en Personas y Permisos qué roles los tienen y quién pertenece a esos roles.
Los módulos contrib amplían mucho Drupal, pero aportan código propio. Los módulos sin mantenimiento activo y los desarrollos propios antiguos son a menudo la razón por la que se aplaza una actualización de PHP. Encontrará más sobre las dependencias en Comprobar vulnerabilidades en las dependencias de Composer.
Lo que logra una actualización de Drupal y lo que no
Una actualización del núcleo o de un módulo cierra errores en ese código y puede permitir versiones más recientes de PHP. No parchea PHP, no elimina archivos ajenos de sites/default/files, no restablece permisos y no borra cuentas creadas a escondidas. Además, la caché puede seguir entregando contenido manipulado hasta que se vacíe. Ante una sospecha, deben renovarse el hash salt y el acceso a la base de datos.
En las instalaciones multisitio, varios sitios web comparten el mismo código, pero bajo sites/ cada uno tiene su propio settings.php y su propio directorio files. Revise entonces cada sitio por separado. Un hallazgo en un sitio suele afectar también a todos los demás, por el código compartido.
¿Cómo ayuda PHP SOS en concreto?
- Revisamos el PHP web y el PHP de CLI de su servidor Drupal y hacemos que se confirmen el parche y el reinicio.
- Guardamos registros y datos y comparamos el estado del código con su repositorio o con los paquetes originales.
- Controlamos
settings.php, el directoriofiles, las reglas del servidor, los roles y los permisos. - Si lo desea, nos encargamos del mantenimiento continuo en el contrato de mantenimiento de seguridad, para que las actualizaciones de PHP y de Drupal no vuelvan a desfasarse.
Preguntas frecuentes
¿Ayuda una actualización de seguridad de Drupal contra PHP2Shell?
No. Las actualizaciones de Drupal cierran errores en el núcleo y en los módulos de Drupal. PHP2Shell está en el PHP del servidor y requiere una actualización de PHP o un backport confirmado, además del reinicio de todos los procesos de PHP.
¿Dónde muestra Drupal la versión de PHP?
En el informe de estado, en Informes. Con Drush, drush status muestra la versión de PHP de la línea de comandos. Ambos datos pueden diferir, y en ninguno de los dos se reconoce con seguridad un backport.
¿Protege el .htaccess de la carpeta files también con Nginx?
No. El .htaccess creado por Drupal solo lo interpreta Apache. Con Nginx necesita una regla propia en la configuración del servidor que bloquee los archivos PHP del directorio files.
¿Qué significa trusted_host_patterns?
El ajuste de settings.php determina bajo qué nombres de host responde Drupal. Protege frente a ataques mediante indicaciones de host manipuladas y debe estar en toda instalación en producción.