PHP2Shell: vulnerabilidad crítica de PHP — ¿está en riesgo su web?

Están afectadas todas las versiones de PHP que, dentro de su propia rama, son anteriores a 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y eso significa casi todos los sitios web en PHP que esta semana nadie ha actualizado todavía. El primer trabajo de hoy es averiguar qué versión atiende su sitio web y actualizarla, porque no existe una solución alternativa completa y el propio anuncio de PHP dice que actualizar es la única elección segura.

El miércoles 21 de octubre el equipo de PHP publicó a la vez cuatro versiones de emergencia. El par de vulnerabilidades que esas versiones corrigen ha recibido el nombre PHP2Shell, y ese nombre describe el resultado con precisión: de una petición de red a la ejecución de código en el servidor. Este artículo trata de qué se ha encontrado exactamente, de cómo saber si le afecta y de en qué orden actuar, también cuando no pueda actualizar de inmediato.

Qué es PHP2Shell y qué ocurrió el 21 de octubre

El anuncio oficial dice que 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos vulnerabilidades críticas que pueden permitir a un atacante no autenticado la ejecución remota de código (RCE), y que a todos los usuarios de PHP se les recomienda con firmeza actualizar de inmediato. En el mismo anuncio hay también una frase que determina todo el resto de este artículo: no existe una solución alternativa completa, y actualizar es la única elección segura.

PHP ha asignado a ambas vulnerabilidades una puntuación base CVSS v4.0 de 9,2 sobre 10, pero se trata de dos fallos distintos, con un mecanismo distinto y, como verá más adelante, también con un grado de confirmación distinto, y es precisamente esta segunda diferencia la que en la práctica decide por qué servidor conviene empezar.

CVE-2026-109618 — memoria dañada tras un out-of-memory (OOM). Cuando PHP se queda sin memoria, usa longjmp() para interrumpir el tratamiento de la petición. La descripción oficial indica que, en algunos momentos, la memoria de la petición es alcanzable antes de estar inicializada por completo; si justo entonces falla la asignación de memoria, la interrupción no se gestiona de forma correcta y queda una memoria no válida que el código de cierre todavía lee, o sobre la cual toma una decisión.

Hay un detalle que cambia a quién alcanza esta amenaza: el out-of-memory se provoca con una petición multipart preparada a propósito, y en ella no tiene que haber ningún archivo subido. La descripción oficial menciona varios problemas del tratamiento multipart, entre ellos una petición sin una longitud declarada que se pueda utilizar, una parte con un número de cabeceras sin límite y campos de archivo vacíos que no se cuentan contra los límites. Eso significa que la petición puede ser muy pequeña y caber dentro de los límites ordinarios de post_max_size y de memory_limit.

CVE-2026-109619 — estado global obsoleto. En un proceso de PHP se conserva, entre una petición y la siguiente, un estado global: datos de errores, de sesiones, de objetos y de extensiones. La descripción oficial dice que ese estado hay que restablecerlo antes de que se libere la memoria de la petición. Si el restablecimiento lo interrumpe un error fatal, o si en el momento del cierre el diagnóstico vuelve a rellenarlo, la memoria se libera pero el puntero hacia ella permanece. Esta clase de fallo se conoce internacionalmente como utilización después de liberación (use-after-free).

A continuación viene la condición que hace esta vulnerabilidad más difícil de lo que suena al leerla: el puntero obsoleto solo lo puede usar una operación que ocurre antes de la inicialización ordinaria de la petición, y la descripción oficial nombra dos casos confirmados de ese tipo, el diagnóstico INI y el tratamiento del progreso de subida de la sesión. Además, la petición posterior del atacante tiene que llegar exactamente al mismo proceso en el que surgió el estado dañado, de modo que un intento aislado rara vez tiene éxito, y la descripción indica de forma expresa que varios procesos y su sustitución reducen las probabilidades, pero no eliminan la propia condición.

Con qué facilidad se explota y frente a qué está demostrado

Aquí conviene ser precisos, porque es justo en este punto donde la mayor parte de los artículos que circulan por internet exagera el alcance hacia un lado o hacia el otro.

No hace falta una contraseña, y tampoco hace falta que alguien pulse algo en el sitio web: en el vector CVSS eso se ve como PR:N y UI:N. En ese mismo vector, sin embargo, están AC:H y AT:P, de modo que la complejidad del ataque se valora como alta y el ataque tiene condiciones previas adicionales. En la práctica eso significa intentos repetidos, y el éxito depende de la compilación de PHP, de las extensiones, del comportamiento del frontal y de la disposición de la memoria. Así que no: con una petición ordinaria no basta, pero al atacante tampoco le cuesta nada, porque nada limita el número de intentos.

El grado de prueba no es el mismo en los dos fallos, y esa diferencia importa a la hora de decidir cuánta prisa hay que darse. En el caso de CVE-2026-109618, una RCE completa ha quedado confirmada contra mod_php con los límites de entrada y de memoria que vienen por defecto; sobre PHP-FPM, la misma descripción dice que el análisis del código fuente lo considera vulnerable, pero una explotación completa de PHP-FPM no se ha demostrado. FrankenPHP se menciona allí como análogo de mod_php, y LSAPI como análogo de PHP-FPM, en ambos casos sin una explotación que se haya verificado.

En el caso de CVE-2026-109619, la vía del ciclo de vida de la sesión se ha probado tanto contra mod_php como contra PHP-FPM, mientras que la otra vía, la que pasa por la traza de un error fatal, ha quedado confirmada solo contra mod_php.

De ahí se sigue un orden práctico: si su sitio web funciona sobre mod_php, usted está en primera línea, porque es precisamente allí donde los dos fallos están confirmados. En el caso de PHP-FPM y de LiteSpeed el riesgo es real, pero de momento está confirmado solo en parte. En ninguno de estos casos eso es un motivo para esperar: es un motivo para saber por qué servidor empezar.

Cómo transcurrió esta semana, hora a hora

La cronología no es una curiosidad: explica por qué las recomendaciones de las primeras horas diferían de las que están en vigor ahora, y por qué una parte de los artículos que siguen circulando por internet está ya desactualizada.

La tarde del 20 de octubre se sabía que algo venía, pero no se sabía qué era exactamente: PHP había anunciado una publicación de emergencia, y la página de estado de CloudLinux deja constancia, esa misma tarde, de que estaba previsto publicar los datos técnicos y las versiones afectadas en el momento de la publicación del día siguiente. La descripción técnica, en aquel momento, todavía no era pública.

Al día siguiente la situación había cambiado, y no a mejor: la mañana del 21 de octubre CloudLinux constata que ya circula públicamente un código de explotación, y a las 09:08 UTC distribuye un conjunto de reglas del cortafuegos de aplicaciones web (WAF) que bloquea el patrón de petición de explotación conocido. Dieciocho minutos después aparece, en esa misma página, la frase que mejor caracteriza esta semana: ya se observan intentos que corresponden a ese patrón, de modo que alguien ya buscaba servidores que todavía no tenían el parche de seguridad.

Los parches de seguridad de PHP se publicaron a las 14:00 UTC, lo que significa que entre una muestra de explotación ya disponible en público y un parche disponible en público pasaron varias horas, y que durante esas horas los intentos de ataque ya estaban en curso.

Una salvedad es justo decirla aquí: el mundo no estaba del todo sin parche, porque el anuncio de PHP dice que las distribuciones de Linux y los proveedores de soporte a largo plazo recibieron los parches por adelantado, de modo que para una parte de los servidores la actualización estuvo disponible antes que para los demás, mientras que de forma pública no estuvo disponible para nadie.

Después empezó la parte más larga, que continúa todavía: la distribución de los paquetes. Quienes mantienen los sistemas operativos y las plataformas de hosting construyen sus paquetes por separado, y esos paquetes aparecen en cuestión de horas o de días, cada uno a su propio ritmo. Justo en esta fase se encuentra una gran parte de quienes usan hosting compartido, y por eso la pregunta «¿ha salido ya el parche?» y la pregunta «¿está el parche en mi servidor?» son esta semana dos preguntas distintas, con respuestas distintas.

¿Está en riesgo su web?

En los avisos oficiales, los intervalos de versiones afectadas están escritos así: todo lo anterior a 8.2.35, todo lo anterior a 8.3.36, todo lo anterior a 8.4.27 y todo lo anterior a 8.5.12, cada intervalo dentro de su propia rama.

Hay un detalle que invita a equivocarse: el número que muestra php -v no siempre lo dice todo. Las distribuciones de Linux y las plataformas de hosting suelen trasladar el parche a una versión anterior sin cambiar el número de esa versión, y lo que cambia es solo el número de publicación del paquete. En ese caso, 8.4.26 puede estar ya corregida, y puede también no estarlo. La única forma de saberlo es mirar la descripción del paquete o preguntar al proveedor, porque el propio número de versión no responde a esa pregunta.

Aparte quedan las versiones más antiguas. PHP 8.1 y las anteriores ya no reciben actualizaciones regulares del proyecto PHP; aun así, dada la gravedad, el equipo de seguridad ha preparado parches mínimos de código fuente para las versiones 7.4, 8.0 y 8.1, destinados a quienes compilan desde el código fuente o no tienen acceso al soporte de quien mantiene su distribución. El anuncio recomienda, en el mismo lugar, ponerse en contacto con el propio proveedor, porque una parte de las distribuciones y de los proveedores de soporte a largo plazo traslada los parches. Si su sitio web funciona sobre PHP 7.x, el problema de verdad no es esta semana: el problema de verdad es que la próxima vez el parche puede no existir siquiera. Y PHP 8.2, que esta vez sí recibió el parche, llega a su fin de vida (EOL) el 31 de diciembre de 2026.

Cómo comprobar la versión, según dónde viva la web

La comprobación lleva minutos, y conviene hacerla en cada sitio web por separado, no en cada servidor: en un mismo servidor suelen convivir sitios web con versiones de PHP distintas, y por lo general es precisamente el más antiguo, aquel del que todo el mundo se ha olvidado, el que sigue siendo accesible desde internet.

Hosting compartido con cPanel. La versión la muestra la sección MultiPHP Manager, en la que cada dominio tiene su propia fila; Plesk usa PHP Settings para lo mismo, dentro de cada suscripción. En ambos casos conviene asegurarse de que se está mirando el dominio del que se habla, y no el valor por defecto del servidor.

Servidor propio o servidor privado virtual (VPS). En la línea de órdenes lo muestra php -v, pero con una salvedad importante: el PHP de la línea de órdenes suele ser una versión distinta de la que atiende las peticiones HTTP. La respuesta más fiable la da el mismo camino por el que funciona el sitio web, es decir, el ejecutable indicado en la sección pool de la configuración de PHP-FPM.

Contenedores. Si el sitio web funciona en un entorno Docker, la versión la determina la imagen, no la máquina anfitriona, así que hay dos pasos: reconstruir la imagen a partir de una imagen base ya actualizada y, después, reiniciar los contenedores. Una imagen construida antes del 21 de octubre no contiene el parche, con independencia de cuántas veces se haya reiniciado el contenedor.

Si no hay acceso a ninguno de estos. Entonces la pregunta es para el proveedor de hosting, y esta semana es una pregunta del todo normal, para la cual ya tienen preparada una respuesta. La formulación que ahorra correspondencia es esta: «¿Qué versión de PHP atiende mi dominio, contiene el parche de seguridad de PHP2Shell y, si todavía no lo contiene, en qué fecha lo tendrá?»

Qué hacer hoy

El orden de hoy es el siguiente: primero actualizar PHP y reiniciar todo lo que lo ejecuta, después comprobar que a quienes visitan el sitio web les atiende de verdad la versión nueva, a continuación comprobar si el repositorio de paquetes que se utiliza ha publicado siquiera el parche y, solo después de eso, buscar rastros. El primer paso lleva minutos, el último puede llevar días, y precisamente por eso no conviene cambiarlos de sitio.

Primero, actualice. En un hosting gestionado lo hace el proveedor, y el trabajo de usted es formular la pregunta y obtener una fecha. Si administra el servidor usted mismo, después de actualizar los paquetes hay que reiniciar aquello que ejecuta PHP, ya sea Apache, PHP-FPM o LSAPI. Este paso se omite con una frecuencia que sorprende: el paquete ya se ha sustituido, pero los procesos viejos siguen trabajando con el código viejo, de modo que la comprobación muestra la versión nueva mientras a quienes visitan les atiende la vieja.

Segundo, compruebe que la actualización está aplicada de verdad — por el mismo camino por el que funciona el sitio web, no a través de la línea de órdenes.

Tercero, si usa un repositorio de paquetes mantenido por voluntarios, compruebe si ese repositorio ha publicado el parche. En el anuncio de PHP hay un aviso aparte sobre rpms.remirepo.net: a quienes lo usan se les recomienda pasar a los paquetes de la distribución o compilar desde el código fuente.

Cuarto, solo después compruebe si en el sitio web hay rastros. Actualizar cierra la puerta, pero no responde a la pregunta de si alguien ha entrado ya por ella.

Si no puede actualizar de inmediato

Lo que sigue conviene leerlo con una idea clara: ninguno de los pasos que aquí se mencionan sustituye a la actualización, y el anuncio de PHP lo dice de forma directa.

Frente a CVE-2026-109618, el anuncio menciona retirar la memoria límite, con memory_limit=-1, y además de forma que la aplicación no pueda reescribir ese valor, por ejemplo con php_admin_value en la configuración de PHP-FPM o de Apache, comprobando que ningún otro ajuste vuelva a imponer un límite finito. Hay que entender lo que cuesta esta elección: en un servidor de hosting compartido se cambia un riesgo por otro, porque una sola petición puede ahora consumir toda la memoria disponible. En la descripción de la vulnerabilidad hay también un aviso de no usar RLIMIT_AS ni RLIMIT_DATA, porque pueden hacer que la asignación de memoria falle y conducir así precisamente hacia la vía vulnerable.

Frente a CVE-2026-109619, el anuncio menciona session.upload_progress.enabled=0 y, en el caso de PHP 8.5, fatal_error_backtraces=0, en ambos casos con la indicación de reiniciar después todos los procesos. En la propia descripción de la vulnerabilidad está también pm.max_requests=1, que obliga a PHP-FPM a sustituir el worker de PHP-FPM después de cada petición; es un ajuste del pool de PHP-FPM, y allí se menciona con la salvedad «si el rendimiento no es un factor». En el mismo lugar se dice también aquello que mantiene esta medida dentro de sus justos límites: sustituir los procesos reduce la probabilidad por cada petición, pero no elimina la propia condición.

También es útil aquello que no constituye una solución alternativa, pero que sí reduce la superficie de ataque: un post_max_size conservador, una profundidad de anidamiento de la entrada que sea razonable y un tamaño de subida limitado. Son valores buenos en cualquier semana, no solo en esta.

Cómo saber si ya le ha afectado

Después de actualizar conviene revisar los registros del servidor HTTP de los últimos días. Lo que hay que buscar es un número inusualmente alto de peticiones multipart hacia una misma dirección, y aquí es fácil buscar en el sitio equivocado: suelen ser pequeñas y caber en los límites ordinarios, así que por el tamaño no se van a encontrar. Más elocuentes resultan las rachas súbitas de errores 500 que empiezan y terminan sin un motivo visible, porque un ataque que se apoya en quedarse sin memoria fracasa mucho más a menudo de lo que tiene éxito, y cada intento fallido deja un error.

En el sistema de archivos importan las horas de modificación: un archivo PHP que haya cambiado de noche, cuando nadie trabajaba, hay que poder explicarlo. Conviene revisar también las tareas programadas y las entradas que aseguran un arranque automático después de un reinicio, porque para un atacante que ya ejecuta código el primer trabajo es afianzarse, de modo que el acceso sobreviva precisamente a la actualización que usted acaba de instalar.

Aparte, conviene revisar la lista de cuentas de administrador y las contraseñas y las claves de la aplicación. Si ha habido ejecución de código, todo lo que el servidor conoce hay que darlo por leído, también los datos de conexión a la base de datos y las claves de API que están en el archivo de configuración.

Si algo de esto no tiene buena pinta, la limpieza es un trabajo aparte, con su propio orden, y conviene hacerlo con método, no borrando de uno en uno los archivos sospechosos. Lo hemos descrito por separado, en cómo se recupera una web hackeada, y, si prefiere que lo haga otra persona, la recuperación de webs hackeadas es un servicio distinto, con una secuencia fija: aislamiento, limpieza, eliminación de la causa y comprobación de que la web ha salido de las listas de advertencias de los buscadores.

Cuando el suceso se convierte en un incidente notificable

Si hay motivos para pensar que el atacante ha accedido a datos personales, la cuestión técnica se vuelve también jurídica. El Reglamento (UE) 2016/679, el RGPD, prevé un plazo que no empieza en el ataque, sino en el momento en que el responsable del tratamiento tiene conocimiento de la brecha de datos personales: si es posible, a más tardar 72 horas para la notificación a la autoridad de control. El deber no nace cuando es improbable que la brecha entrañe un riesgo para los derechos y libertades de las personas físicas y, si el riesgo es alto, hay que informar también a las propias personas; ese deber tiene, asimismo, sus excepciones en el reglamento.

La utilidad práctica de lo anterior es una sola: el momento en que en los registros aparece algo sospechoso no es el momento en que empiezan a correr las 72 horas, sino el momento en que hay que aclarar si la brecha ha ocurrido siquiera. Una racha aislada de errores 500 que, como queda descrito más arriba, casi siempre es un intento fallido, no constituye por sí misma una brecha. Precisamente por eso no conviene aplazar esa aclaración hasta «cuando haya menos trabajo», y precisamente por eso los registros hay que conservarlos antes de que la rotación los reescriba: son la única prueba tanto de lo que ocurrió como de lo que no ocurrió.

Si tiene varios sitios web a su cargo

Para las agencias y para las empresas que tienen varios sitios web, esta semana es menos una tarea técnica que una tarea de organización, y el orden que funciona es sencillo: primero la lista, después las versiones y después la actualización por orden de prioridad.

La prioridad no la marca la importancia del sitio web, sino la accesibilidad y qué es lo que lo atiende. Arriba están los sitios web de acceso público que funcionan sobre mod_php, porque es precisamente allí donde ambas vulnerabilidades están confirmadas; después va el resto de lo que es público y, solo después, los sistemas internos que están detrás de un cortafuegos. Los entornos de prueba y de desarrollo de los que todo el mundo se olvida hay que incluirlos en la lista de forma obligatoria, porque a menudo funcionan sobre una versión de PHP más antigua y a menudo son accesibles desde internet, ya que en algún momento así resultaba más cómodo.

Los sitios web que administra otra persona permanecen en la lista, pero con otra columna: a quién se le ha enviado la pregunta y en qué fecha se ha recibido la respuesta. Esa columna acaba resultando más valiosa que las demás, porque es precisamente ella la que muestra qué proveedor responde y cuál no.

Qué significó en este caso el hosting gestionado

Esta semana muestra con bastante claridad dónde está el límite entre la plataforma y la aplicación, así que es justo contar cómo se vio todo ello desde nuestro lado.

Nuestros servidores funcionan sobre CloudLinux y llevan Imunify360 incorporado. Cuando la muestra de explotación empezó a circular en público, CloudLinux dejó constancia en su página de estado de que el conjunto de reglas de cortafuegos que bloquea el patrón de explotación conocido se había distribuido a las 09:08 UTC, varias horas antes de que PHP publicara el propio parche a las 14:00, y antes de que en esa misma página apareciera la entrada según la cual los intentos ya se estaban observando. A lo largo del día siguieron dos añadidos más, de los cuales el segundo bloquea la herramienta de explotación que ya estaba disponible en público. Todo ello ocurrió de forma automática, sin participación del cliente. En el sector, una medida de este tipo se llama virtual patching: una regla del cortafuegos de aplicaciones web bloquea la explotación de la vulnerabilidad sin modificar el propio código vulnerable.

Y ahora, lo que una frase así no significa, porque es justo en este punto donde el sector ha vendido esta semana la mayor cantidad de exageraciones. Una regla de cortafuegos bloquea patrones de ataque conocidos, y esa misma palabra es la que usa también CloudLinux. Esa misma página llama a la medida una solución temporal, no un parche completo. No es invulnerabilidad, y el propio CloudLinux sigue recomendando actualizar PHP en cuanto los paquetes estén disponibles. La diferencia entre «protegido» y «parcheado» es esta semana del todo concreta, y vender lo uno como lo otro sería deshonesto.

Cómo se presenta el propio parche es una buena ilustración de aquello sobre lo que advertimos más arriba. Nuestros servidores recibieron una compilación nueva de ea-php84 la tarde de ese mismo día, unas horas después de la publicación de PHP. El número de versión no cambió: php -v sigue escribiendo 8.4.26 y no 8.4.27, y lo único que desde fuera delata el cambio es la fecha de compilación, que saltó del 9 al 21 de octubre. Así es exactamente como se ve un parche que se ha trasladado a una versión anterior, y por eso la pregunta al proveedor de hosting vale más que el número que muestra la pantalla.

Por eso, el valor que aquí aportó el hosting gestionado no es la invulnerabilidad, sino una ventana más estrecha: las horas en las que la muestra de explotación ya circulaba y los intentos ya estaban ocurriendo quedaron cubiertas mediante el bloqueo de los patrones conocidos, y no quedaron a la espera. Y, después de eso, que alguien siga los paquetes y reinicie los procesos, en lugar de esperar a que el cliente se dé cuenta. Nuestro hosting gestionado empieza desde 45 € al mes, y son precisamente las semanas de este tipo aquello por lo que se paga esa cantidad.

Si su sitio web funciona ahora en un lugar donde no se consigue respuesta a la pregunta por la versión de PHP y por la fecha de la actualización, eso ya constituye, por sí mismo, una respuesta. Hablemos del traslado: una migración suele poder hacerse sin interrupción del servicio.

Tras la actualización hay que reiniciar más de lo que parece

Un proceso que permanece vivo entre una petición y la siguiente no es ninguna rareza: así funciona un pool ordinario de PHP-FPM y también mod_php, y es precisamente contra ellos contra lo que la ejecución de código ha quedado confirmada. Por eso CVE-2026-109619 no es la amenaza de unas configuraciones especiales, sino un problema de la configuración ordinaria.

De ahí sale el paso que con más frecuencia se omite: sustituir el paquete no afecta al proceso que ya está en marcha. Después de actualizar hay que reiniciar cada proceso que ejecuta PHP, y eso alcanza también a aquellos procesos que nadie suele tocar. Los procesos de PHP que llevan mucho tiempo en marcha pueden pasar semanas sin reiniciarse, así que después de la actualización conviene enumerarlos aparte y comprobar que cada uno de ellos se ha levantado de nuevo.

La pregunta correcta para esa comprobación no es, por tanto, «¿qué muestra php -v?», sino «¿se inició cada proceso que ejecuta PHP después de que se sustituyera el paquete?».

Por qué no basta con «nosotros no subimos nada»

Una objeción frecuente suena más o menos así: nuestro sitio web es un sitio web corporativo, en él no hay formulario de subida ni cuentas de usuario, luego esto no nos concierne. Por desgracia sí concierne, y la razón es exactamente la que queda descrita más arriba: el ataque no necesita un archivo subido, le basta una petición multipart preparada de la forma correspondiente, y esa petición se puede enviar a cualquier dirección que responda con PHP. Que en la página exista un formulario no es una condición previa, porque el atacante no rellena ningún formulario.

Tampoco importa que el sitio web sea pequeño. Los ataques contra vulnerabilidades de este tipo se lanzan de forma masiva, indiscriminada y automática, y nadie hace una selección según el número de visitantes. La unidad Unit 42 de Palo Alto Networks informó, el día de la publicación, de más de 22,6 millones de instancias de PHP accesibles desde internet y potencialmente afectadas; ninguna de ellas ha sido elegida en particular.

La otra objeción se refiere a WordPress y a los plugins. Esta vez tampoco sirve, solo que en la dirección contraria: la vulnerabilidad está en el propio PHP, no en WordPress, ni en Laravel, ni en un plugin. Eso significa que actualizar los plugins no resuelve este problema y, al mismo tiempo, que está afectado cada sitio web que funcione sobre PHP, con independencia de aquello sobre lo que esté construido.

Qué conviene conservar de esta semana

A quienes ya lo tenían todo en orden no les salvó una reacción rápida, sino tres cosas que estaban dispuestas de antemano: se sabía qué sitio web funcionaba sobre qué versión de PHP, se sabía quién responde de la actualización, y había copias de seguridad de las que se había comprobado de verdad que el sitio web se puede restaurar. Ninguna de esas tres cosas se puede improvisar el día en que el aviso ya está publicado, y precisamente por eso esta semana fue media hora de trabajo para unos equipos y dos días para otros.

Si de esta semana hay que llevarse una sola tarea para que la próxima vez resulte más fácil, esa tarea es una lista: cada sitio web, su versión de PHP, la forma en que se ejecuta, su proveedor de hosting y la persona que tiene permiso para pulsar «actualizar». El próximo aviso de este tipo llegará, y la única pregunta entonces será cuánto se tarde en responder a «¿nos afecta esto?».