PHP2Shell y la seguridad de las plataformas PHP. Qué hacer antes y después del parche

PHP2Shell es el nombre de dos vulnerabilidades críticas del intérprete PHP, CVE-2026-109618 y CVE-2026-109619, que pueden permitir la ejecución remota de código en el servidor sin autenticación. El 21 de octubre de 2026, el proyecto PHP publicó las versiones de emergencia 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregirlas. El riesgo afecta a las instalaciones vulnerables que atienden peticiones web con PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed, según el aviso oficial de PHP.

Lo más revelador fue dónde estaba el fallo. Afectaba al intérprete sobre el que funcionan Drupal, WordPress y muchas otras plataformas. Para corregirlo había que actualizar PHP, aunque el CMS y sus plugins estuvieran al día. Y en muchas organizaciones, esa es justo la capa de la que nadie se siente del todo responsable.

¿Qué sistemas están expuestos a PHP2Shell?

PHP no es solo el lenguaje de millones de webs. También va integrado en consolas de gestión, dispositivos de red y productos de terceros. El Centro Nacional de Ciberseguridad de Países Bajos (NCSC-NL) mantiene un inventario de productos evaluados por su exposición a PHP2Shell. En muchos de ellos, el administrador ni siquiera puede actualizar PHP por su cuenta y depende del fabricante.

De ahí la primera lección. La exposición real de una organización casi nunca coincide con su lista de «aplicaciones PHP». Incluye imágenes de contenedor heredadas, entornos de preproducción olvidados, herramientas internas y productos que llevan PHP dentro sin decirlo.

¿Quién debe actualizar PHP en una plataforma gestionada?

En una plataforma gestionada, la actualización del intérprete PHP suele corresponder al equipo de sistemas, al servicio de alojamiento o al proveedor que opera la plataforma. El contrato y el reparto de responsabilidades deben dejar claro quién instala el parche, reinicia los procesos y verifica que la versión corregida esté en uso.

El código de la aplicación es cosa del equipo de desarrollo. En este caso, su papel era comprobar la compatibilidad del CMS, el framework y las dependencias con la versión corregida de PHP.

En el perímetro, un cortafuegos de aplicaciones web (WAF) o una red de distribución de contenidos (CDN) podían aplicar reglas temporales mientras se desplegaba el parche. En los productos de terceros que integran PHP, la corrección dependía del fabricante. Aislar los sistemas afectados era una opción para reducir la exposición mientras llegaba la actualización.

Cuando cada parte da por hecho que otra se ocupará del intérprete, el parche existe pero no llega a producción.

Cómo responder a PHP2Shell y verificar que el parche funciona

La respuesta a PHP2Shell empieza por identificar los sistemas expuestos y termina cuando se ha verificado el parche en producción, se han investigado posibles indicios de intrusión y se ha comunicado el resultado.

1. Detectar el aviso. Seguir los canales oficiales de PHP, de la distribución y de los proveedores.
2. Evaluar el impacto. Saber en horas qué sistemas ejecutan qué versión de PHP, con qué modo de ejecución y si están expuestos a internet.
3. Mitigar la exposición. Aplicar las medidas temporales del aviso del 21 de octubre si el parche no se puede desplegar de inmediato. El 23 de octubre, PHP publicó además un aviso sobre una vulnerabilidad relacionada en la gestión de sesiones, CVE-2026-115560, con una medida específica para determinadas configuraciones.
4. Parchear PHP. Instalar una versión corregida o el paquete de seguridad de la distribución. Algunos proveedores incorporan el parche sin adoptar el número de versión oficial de PHP. Para confirmarlo, hay que comprobar el aviso de seguridad del proveedor y la versión exacta del paquete instalado.
5. Validar el despliegue. Reiniciar los procesos que atienden peticiones web y comprobar que usan el binario corregido. Un parche instalado con los procesos antiguos todavía en marcha deja esos procesos expuestos.
6. Revisar si hubo intrusión. CISA añadió ambas vulnerabilidades a su catálogo de vulnerabilidades explotadas (KEV) el 26 de octubre. Según Acquia, se observó al menos un intento de explotación antes de que se publicara el parche. La Drupal Association anunció que estaba auditando su infraestructura en busca de actividad sospechosa anterior a la actualización. Cobertura de la inclusión en el catálogo KEV · Auditoría de la infraestructura de Drupal.org
7. Comunicar el estado. Explicar qué se ha hecho, qué queda pendiente y qué debe hacer cada parte.

Instalar el parche es solo el cuarto paso. Para cerrar el incidente hay que confirmar que la corrección está activa en todos los sistemas afectados y revisar qué pudo ocurrir mientras estuvieron expuestos.

Cómo Acquia aplicó el parche de PHP2Shell y mantuvo los sitios Drupal en línea

Acquia, una plataforma gestionada de referencia en el ecosistema Drupal y de la que hiberus es partner, explicó cómo gestionó PHP2Shell en su publicación del 2 de noviembre. Según su relato:

• Recibió el aviso bajo embargo el 19 de octubre y activó ese mismo día su proceso de respuesta a incidentes.
• Tenía su propia versión corregida de PHP compilada y probada antes de la publicación oficial.
• Empezó a desplegarla diez minutos después de que PHP publicara el parche.
• Completó el despliegue en unas tres horas en Acquia Cloud Next, su plataforma de contenedores, y ese mismo día en el resto de las aplicaciones Drupal alojadas.
• Los sitios siguieron en línea y los clientes no tuvieron que intervenir.

La rapidez fue posible gracias a tres condiciones previas. Acquia formaba parte del circuito de divulgación coordinada, controlaba la compilación del intérprete y asumía la operación de la capa de aplicación.

Lo más valioso de su publicación, sin embargo, es su transparencia. Algunos de sus servicios de gestión dependían de un proveedor cloud que aún no había publicado su parche, y Acquia optó por desconectarlos de forma preventiva. Durante ese tiempo, los clientes no pudieron acceder a la consola, desplegar código ni abrir incidencias en línea, aunque sus webs siguieron funcionando y el soporte telefónico seguía disponible. Explicar abiertamente estas decisiones y lo que se va a mejorar también es parte de gestionar bien un incidente.

De ahí sale una vara de medir razonable para cualquier proveedor de plataformas gestionadas. Debe poder parchear el intérprete sin que el cliente tenga que pedirlo, hacerlo sin interrupciones siempre que sea posible, tener controladas sus propias dependencias y comunicar qué se ha hecho y qué queda pendiente.

Cómo preparar una plataforma PHP para la próxima vulnerabilidad crítica

Da igual si se usa Drupal, WordPress, Symfony, Laravel, Magento o un desarrollo a medida. Estas prácticas marcan la diferencia antes del próximo aviso.

• Inventario actualizado de versiones de PHP. Incluir contenedores, entornos de preproducción y productos de terceros, además de las webs principales.
• Responsables claros por capa. Dejar por escrito quién actualiza el intérprete, en qué plazo y cómo lo comunica.
• Migración de las versiones sin soporte. PHP 8.1 y anteriores ya no reciben actualizaciones regulares del proyecto. Para este incidente, el equipo de PHP publicó correcciones puntuales de código fuente para PHP 7.4, 8.0 y 8.1. PHP 8.2 dejará de recibir correcciones de seguridad del proyecto el 31 de diciembre de 2026. Calendario oficial de soporte de PHP
• Despliegue automatizado y reversible. Preparar las actualizaciones de PHP para poder ejecutarlas en cuestión de horas.
• Medidas temporales probadas. Preparar las reglas del WAF y los cambios de configuración antes de necesitarlos.
• Ensayos periódicos. Un simulacro tranquilo enseña más que un incidente real a las dos de la madrugada.

Nada de esto se improvisa cuando aparece una vulnerabilidad crítica. La preparación forma parte del mantenimiento diario de la plataforma.

Qué aprendimos en hiberus al gestionar PHP2Shell

En hiberus vivimos PHP2Shell de cerca. En los días posteriores a la publicación del parche realizamos actuaciones en las plataformas de varios clientes. La experiencia confirma que la seguridad de una plataforma depende tanto de su código como de la infraestructura, las dependencias, las versiones y la capacidad de respuesta de quienes la operan.

Por eso integramos la seguridad en el desarrollo, el mantenimiento, la evolución y la operación de plataformas Drupal, WordPress y desarrollos PHP a medida. Nuestra prioridad es que, cuando llegue la próxima vulnerabilidad, nuestros clientes sepan qué tienen, quién hace qué y cuánto tardarán en estar protegidos.

Habrá más vulnerabilidades como esta. Lo que sí depende de cada organización es cómo de preparada está cuando lleguen.