Añádelo como fuente preferida en Google
El 21 de octubre de 2026, los atacantes ya estaban lanzando solicitudes contra sitios web con solicitudes diseñadas para aprovechar dos vulnerabilidades críticas de PHP conocidas como PHP2Shell. Los parches de seguridad oficiales aún no estaban disponibles, pero nuestros equipos de ingeniería y seguridad ya estaban trabajando para proteger los sitios web alojados en Kinsta.
La respuesta implicó varias acciones simultáneas. Nuestro equipo activó de urgencia las reglas del cortafuegos de Cloudflare, ajustó las configuraciones de PHP y se preparó para realizar el despliegue de parches en cientos de miles de contenedores en cuanto estuvieran disponibles. Al mismo tiempo, nuestro equipo de soporte estaba respondiendo a una avalancha de preguntas de clientes preocupados por sus sitios web.
El 23 de octubre, nuestras protecciones de Cloudflare ya habían bloqueado más de 550.000 solicitudes dirigidas a esas vulnerabilidades. Además, habíamos realizado el despliegue de las actualizaciones de seguridad necesarias de PHP en toda nuestra plataforma de alojamiento y no encontramos indicios de que se hubieran producido accesos no autorizados.
Así es como se desarrolló la respuesta, desde los primeros indicios de explotación hasta el lanzamiento del parche y el trabajo que vino después.
Preparándonos para PHP2Shell antes de que estuvieran disponibles los parches
El 20 de octubre, el equipo de seguridad de PHP anunció una próxima actualización de seguridad crítica, prevista para el día siguiente. El anuncio advertía de dos vulnerabilidades con una puntuación de gravedad CVSS 4.0 de 9,2 y animaba a los usuarios de PHP a prepararse para actualizar sus instalaciones en cuanto los parches estuvieran disponibles.
Las vulnerabilidades, identificadas posteriormente como CVE-2026-109618 y CVE-2026-109619, afectan a la gestión interna de la memoria de PHP y, en determinadas condiciones, podrían permitir a los atacantes ejecutar código de forma remota sin necesidad de autenticación.
El anuncio fue especialmente importante para los sitios web de WordPress, ya que PHP es el que ejecuta la propia aplicación. Actualizar un plugin o un tema de WordPress no bastaba para solucionar estas vulnerabilidades. El entorno de ejecución de PHP subyacente necesitaba parches de seguridad.
Para proveedores de alojamiento como Kinsta, el primer reto fue proteger los sitios web antes de que estuvieran disponibles los parches oficiales. Nuestro equipo empezó a prepararse para el lanzamiento, pero ya estaban apareciendo intentos de explotación.
Según Laszlo Farkas, director de ingeniería de Kinsta, nuestro equipo empezó a detectar solicitudes dirigidas a las vulnerabilidades en las primeras horas del 21 de octubre. Los ingenieros revisaron manualmente los sitios afectados y siguieron vigilando la actividad en busca de indicios de una intrusión exitosa.
Para entonces, ya habíamos tomado medidas para proteger los sitios web de nuestra plataforma.
Cómo activamos las reglas WAF de emergencia de Cloudflare
Todos los sitios web alojados en Kinsta están protegidos por Cloudflare, tanto los entornos de producción como los de staging. Esto permite a nuestro equipo de ingeniería aplicar protecciones de cortafuegos en toda la plataforma de alojamiento sin que los clientes tengan que configurar reglas para cada sitio web por separado.
Antes de que se hiciera pública la vulnerabilidad PHP2Shell, Cloudflare introdujo reglas de emergencia del cortafuegos de aplicaciones web (WAF) para detectar intentos de explotación. Nuestro equipo de ingeniería siguió de cerca el registro de cambios del WAF de Cloudflare a medida que se publicaban nuevas reglas, las revisó y estableció su acción en Bloquear lo antes posible.
Como todos los sitios de Kinsta ya están protegidos por Cloudflare, pudimos aplicar estas medidas de seguridad en toda nuestra plataforma de alojamiento, tanto en los entornos de producción como en los de staging, sin que los clientes tuvieran que hacer nada.
Esa protección a nivel de plataforma era importante porque PHP2Shell no era una vulnerabilidad típica a nivel de aplicación. Los ataques iban dirigidos directamente contra el propio PHP, así que las actualizaciones de seguridad de WordPress o la protección a nivel de plugins no habrían solucionado el problema de fondo.
Las reglas del WAF nos permitieron bloquear los intentos de explotación conocidos mientras preparábamos los parches para PHP. Cloudflare siguió actualizando sus protecciones a medida que los atacantes cambiaban sus técnicas. El informe técnico sobre PHP2Shell describe cómo los atacantes modificaron sus payloads para eludir los sistemas de detección existentes.
Cloudflare también introdujo la detección completa de transacciones, que analiza las señales tanto de la solicitud HTTP como de la respuesta del servidor. Esto proporciona información adicional para identificar solicitudes sospechosas y puede evitar que una respuesta coincidente llegue al solicitante.
Nuestros ingenieros pudieron observar cómo cambiaban los patrones de ataque a medida que se publicaban nuevas reglas.
El 23 de octubre, las protecciones de Cloudflare que cubrían los sitios de Kinsta habían bloqueado más de 550.000 solicitudes dirigidas a PHP2Shell.
Esta cifra representa las solicitudes bloqueadas relacionadas con las vulnerabilidades, no los ataques que tuvieron éxito ni el número de atacantes distintos. Refleja el tráfico sospechoso que gestionaron nuestras protecciones de firewall mientras el equipo trabajaba en el despliegue de las correcciones de PHP.
Añadir protecciones temporales en la configuración de PHP
No nos limitamos a confiar solo en Cloudflare. Mientras esperábamos los paquetes de PHP parcheados, nuestro equipo de ingeniería también implementó cambios en la configuración de PHP en todos nuestros entornos de alojamiento para reducir la exposición a las vías de explotación conocidas.
Uno de los cambios consistió en desactivar la funcionalidad de progreso de subida de archivos de PHP mediante el parámetro session.upload_progress.enabled.
El aviso de seguridad de PHP señala esta configuración como una medida para mitigar ciertas vías de explotación. Desactivarla ayuda a bloquear los ataques que se aprovechan de la gestión del progreso de las subidas de archivos en las sesiones de PHP, aunque no resuelve todas las formas posibles en las que se podrían explotar las vulnerabilidades.
Las reglas del cortafuegos y los cambios en la configuración proporcionaron una protección adicional mientras los parches no estaban disponibles o aún se estaban realizando el despliegue. Sin embargo, seguía siendo necesario actualizar el entorno de ejecución de PHP.
El 23 de octubre, el equipo de PHP publicó un aviso adicional en el que recomendaba mantener desactivado el progreso de subida de sesiones hasta una próxima versión que corrigiera el error. Esto reforzó la medida de precaución que nuestro equipo de ingeniería ya había tomado.
Nuestras reglas de Cloudflare y las protecciones de configuración local se mantuvieron activas durante todo el proceso de implementación de los parches, independientemente de si cada entorno había recibido ya su paquete de PHP actualizado.
Despliegue de parches de PHP en cientos de miles de contenedores
Cuando el equipo de desarrollo de PHP publicó las actualizaciones de seguridad el 21 de octubre, nuestro siguiente reto fue el despliegue de esas correcciones en toda la infraestructura de alojamiento.
Las versiones oficiales incluían PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Sin embargo, Kinsta también admite versiones anteriores de PHP, que requerían correcciones de seguridad de mantenedores externos.
Trabajamos con Freexian, nuestro proveedor de paquetes de PHP, para conseguir paquetes parcheados para las versiones de PHP que se ejecutan en nuestra plataforma, incluidas las versiones más antiguas con soporte a largo plazo.
Los paquetes se fueron publicando poco a poco, no todos a la vez. A medida que cada construcción llegaba a nuestro servidor espejo de paquetes, nuestro equipo de ingeniería la validaba y empezaba el despliegue sin esperar a que todas las ramas de PHP estuvieran listas.
Así es como fue el proceso de implementación:
| Fecha y hora (UTC) | Qué ocurrió |
| 21 de octubre, ~14:00–17:45 | PHP publicó los parches de seguridad. PHP 8.5.12 estuvo disponible en nuestro servidor espejo de paquetes a las 14:24, y el despliegue comenzó a las 15:54. A las 17:45, ya se habían actualizado decenas de miles de contenedores. |
| 21 de octubre, de 18:50 a 19:04 | PHP 8.3.36 ya estaba disponible, y empezó a desplegarse junto con PHP 8.5. |
| 21 de octubre, de 21:17 a 22:28 | Estuvieron disponibles los paquetes parcheados para PHP 7.4, 8.0 y 8.1, y se iniciaron nuevas despliegues a las 22:28. |
| 21-22 de octubre, de 23:25 a 01:37 | Los paquetes de PHP 8.2 y 8.4 llegaron a las 23:25, y la despliegue empezó a las 01:37 del 22 de octubre. |
| 22 de octubre, a las 04:31 | Solo quedaban por actualizar 1.888 contenedores, aproximadamente el 0,5 % del total, que requerían una atención especial. |
| 22 de octubre, 08:26 | Confirmamos una cobertura de protección del 100 % y dimos el incidente por resuelto. |
La capacidad de realizar el despliegue de cambios a esta escala fue uno de los aspectos más importantes de la respuesta.
Farkas destacó la rapidez con la que el equipo pudo desplegar los cambios en toda la infraestructura:
«Esta es la parte de la que estoy más orgulloso. Una vez que se valida un cambio y sabemos que no va a causar ningún fallo, podemos implementarlo en toda la infraestructura en un par de horas».
Esa capacidad permitió a nuestro equipo desplegar paquetes PHP parcheados en cientos de miles de contenedores en cuestión de horas.
Tampoco tuvimos que coordinar las actualizaciones de PHP con cada cliente por separado. Kinsta gestiona PHP a nivel de plataforma, así que, en cuanto el equipo de ingeniería validaba un paquete actualizado, podíamos desplegarlo en todos los entornos afectados sin tener que pedir a los propietarios de los sitios que instalaran las actualizaciones ellos mismos.
Por qué las versiones antiguas de PHP necesitaban correcciones adicionales
La implementación también tuvo que tener en cuenta la diferencia entre las ramas de PHP con soporte oficial y las versiones más antiguas que mantienen otros proveedores.
El proyecto PHP lanzó actualizaciones de seguridad para las versiones de PHP 8.2 a 8.5. Versiones como PHP 7.4, 8.0 y 8.1 ya no recibían actualizaciones de seguridad periódicas directamente del proyecto PHP, aunque los proveedores de soporte a largo plazo podían ofrecer correcciones adaptadas a versiones anteriores.
El backporting permite a los responsables del mantenimiento aplicar correcciones de seguridad a una rama antigua del software sin que los usuarios tengan que actualizar a una versión más reciente de PHP.
Esto significaba que podíamos realizar el despliegue de las actualizaciones de seguridad para esos entornos PHP más antiguos a medida que Freexian lanzaba paquetes parcheados.
Esto también explica por qué el número de versión de PHP por sí solo no siempre te indica si se ha aplicado una corrección de seguridad concreta. Los paquetes mantenidos por los proveedores pueden incluir código parcheado sin mostrar el mismo número de versión que la versión oficial de PHP.
A lo largo del proceso de implementación, seguimos instalando actualizaciones sin dejar de mantener las protecciones adicionales del cortafuegos y de configuración.
Monitorización de ataques y búsqueda de indicios de que el sistema haya sido comprometido
La aplicación de parches fue solo una parte de la respuesta. Nuestro equipo también tenía que determinar si alguno de los intentos de explotación observados había tenido éxito.
Cuando detectamos por primera vez actividad dirigida a sitios web alojados en Kinsta en las primeras horas del 21 de octubre, nuestros ingenieros investigaron manualmente los sitios afectados.
Siguieron vigilando el tráfico sospechoso y realizando comprobaciones aleatorias en los entornos de alojamiento durante todo el incidente, en busca de indicios de que los atacantes hubieran aprovechado con éxito las vulnerabilidades.
Los eventos de seguridad de Cloudflare nos ayudaron a entender qué era lo que estaban atacando y cómo cambiaban los patrones de ataque a medida que publicábamos nuevas reglas. Sin embargo, el recuento de solicitudes bloqueadas por sí solo no nos permitía saber si algún ataque había tenido éxito.
Por eso eran tan importantes las comprobaciones manuales. Nuestro equipo también se mantuvo en estrecho contacto con Patchstack, nuestro socio de Protección contra Vulnerabilidades, compartiendo información sobre las amenazas y los patrones de ataque que ambos equipos observaban. Además, participamos en conversaciones con otros proveedores de alojamiento para intercambiar información y buenas prácticas a medida que la comunidad PHP en general respondía.
Estos esfuerzos complementaron nuestro trabajo con Cloudflare y Freexian. Cloudflare proporcionó protecciones contra los intentos de explotación, Freexian facilitó los paquetes de PHP parcheados y la coordinación con los socios de seguridad ayudó a nuestros ingenieros a entender cómo se estaba desarrollando la amenaza.
Durante todo el incidente, no encontramos ninguna prueba de que se hubieran producido brechas relacionadas con PHP2Shell.
Esa conclusión se basa en el seguimiento y las investigaciones llevadas a cabo durante la respuesta. Esto no significa que no hubiera ataques, como muestran los datos del cortafuegos. Significa que nuestras comprobaciones no detectaron indicios de que se hubiera producido una intrusión con éxito.
Resolución del incidente y verificación continua
El 22 de octubre a las 08:26 UTC, marcamos el incidente de seguridad de PHP como resuelto en nuestra página de estado pública.
Para entonces, ya habíamos implementado actualizaciones de seguridad en toda la plataforma, y todos los sitios estaban protegidos mediante una combinación de parches y medidas de mitigación.
Que se hubiera resuelto el incidente no significaba que dejáramos de comprobarlo. Nuestro equipo siguió verificando los entornos y monitorizando las protecciones incluso después de que se cerrara el incidente público.
Esto fue importante durante una implementación que afectaba a varias ramas de PHP y a cientos de miles de contenedores. A las 04:31 UTC, alrededor del 0,5 % de los contenedores aún necesitaban atención adicional. Nuestros ingenieros siguieron trabajando en esos entornos restantes y verificando los resultados, en lugar de dar por hecho que, solo porque un paquete ya se había parcheado, todas las instalaciones se hubieran actualizado.
Las reglas de Cloudflare y las medidas de protección de la configuración de PHP también se mantuvieron activas durante este trabajo de verificación.
Para los clientes, las actualizaciones de seguridad de PHP no requirieron aplicar parches manualmente ni cambiar de versión.
Respuesta a los clientes que tomaron precauciones adicionales
La respuesta a PHP2Shell fue mucho más allá de los proveedores de alojamiento. A medida que se difundía la noticia de las vulnerabilidades, organismos gubernamentales y otras organizaciones de todo el mundo empezaron a desconectar temporalmente sus sitios web mientras preparaban las actualizaciones de seguridad.
En los Países Bajos, el Centro Nacional de Ciberseguridad desconectó su propio sitio web como medida de precaución. Los sitios web gubernamentales de Alemania, Francia, Bélgica y Finlandia también se suspendieron temporalmente. En Japón, la primera ministra Sanae Takaichi emitió una advertencia urgente en X, instando a los operadores de sitios web a aplicar los parches lo antes posible o a suspender temporalmente los servicios si no podían actualizar de inmediato.
En Kinsta, hemos observado preocupaciones similares entre nuestros clientes. Nuestro equipo de soporte técnico ha recibido un aumento significativo de consultas sobre PHP2Shell, y algunos clientes han empezado a tomar medidas adicionales para proteger sus sitios web.
Entre ellas se incluían el uso de la funcionalidad de suspensión de entornos de MyKinsta para desconectar sitios web, la activación de medidas de protección en todo el sitio mediante la Protección contra Bots o solicitar al servicio de soporte técnico que bloqueara el tráfico entrante a nivel de servidor. Los clientes suspendieron de forma proactiva unos 3.000 sitios web durante el incidente.
Dada la gravedad de las vulnerabilidades y las precauciones que se estaban tomando en otros sitios, estas decisiones eran comprensibles. Sin embargo, el equipo de ingeniería no recomendó a los clientes que desconectaran sus sitios web alojados en Kinsta. Ya habíamos activado las reglas de emergencia del WAF de Cloudflare en toda nuestra plataforma de alojamiento, así que los sitios que permanecieron online siguieron contando con esas protecciones sin que los visitantes dejaran de poder acceder a ellos.
Nuestro equipo de soporte comenzó a aconsejar a los clientes que evitaran las suspensiones innecesarias, mientras que el equipo de ingeniería seguía realizando el despliegue de los parches de PHP.
Una vez que implementamos las actualizaciones de seguridad, revisamos las medidas de suspensión que se tomaron durante el incidente para identificar los sitios web que los clientes desconectaron específicamente a causa de PHP2Shell.
A continuación, nuestro equipo reactivó esos entornos, dejando intactos los sitios que se habían suspendido por motivos ajenos al incidente. Para ello, tuvimos que distinguir las suspensiones preventivas de otras suspensiones intencionadas, en lugar de limitarnos a restaurar todos los entornos que se habían desconectado.
Además de bloquear los ataques y realizar el despliegue de parches, nuestros equipos también tuvieron que ayudar a los clientes a recuperarse de las medidas preventivas que habían tomado durante el incidente.
Qué supuso esta respuesta para los clientes de Kinsta
PHP2Shell requirió la coordinación entre los equipos de Ingeniería, Soporte y varios socios externos de seguridad e infraestructura. Pero la plataforma se encargó por sí misma de aplicar los parches.
Los clientes no tuvieron que estar pendientes de la disponibilidad de cada versión de PHP, determinar qué paquete parcheado necesitaba su sitio web ni instalar las actualizaciones ellos mismos.
Farkas explicó lo que la respuesta significó en última instancia para los clientes de Kinsta:
«Para mí, el mensaje principal es que los clientes no tenían que preocuparse por nada de eso: qué actualizar, cuándo ni cómo. Simplemente estaban protegidos en nuestra plataforma.»
La reacción de los clientes durante el incidente también puso de manifiesto por qué era importante comunicar esas medidas de protección. Algunos clientes desconectaron sus sitios web a pesar de que las reglas de emergencia del WAF ya estaban activas, y nuestros equipos trabajaron posteriormente para restaurar los entornos suspendidos debido a las vulnerabilidades.
Mientras tanto, nuestro equipo de ingeniería desplegó las actualizaciones de seguridad de PHP en cientos de miles de contenedores sin que los clientes tuvieran que gestionar los cambios.
Para ver un resumen de las actualizaciones de seguridad y la resolución del incidente, echa un vistazo a nuestro informe sobre el incidente de seguridad de PHP.
Si quieres saber qué implican estas vulnerabilidades para tu sitio web, lee nuestro artículo relacionado: PHP2Shell: cómo Kinsta protegió los sitios de WordPress.
