Lo que ocurrió el 21 de octubre
Las dos vulnerabilidades tienen las referencias CVE-2026-109618 y CVE-2026-109619, y el sobrenombre PHP2Shell. Están calificadas con un 9,2 sobre 10. En la práctica, una solicitud web bien estructurada es suficiente para ejecutar código en el servidor, incluso antes de que el sitio o la aplicación se inicie. No se necesita cuenta, ni contraseña, ni que el sitio tenga un error: la falla está en PHP en sí mismo.
El incidente comenzó con una filtración. El martes 20 de octubre, a última hora de la tarde, un mensaje en Hacker News anunció dos vulnerabilidades críticas bajo embargo. La empresa watchTowr confirmó esa misma noche que eran reales, y PHP anunció un parche para el día siguiente a las 14:00 UTC. Mientras tanto, circularon páginas que pretendían publicar un exploit, Cloudflare activó reglas de firewall para todos sus clientes desde las 3:02 UTC y observó cómo los atacantes modificaban sus cargas para esquivarlas. Desde entonces se sabe que los señuelos de Amazon habían recibido un primer intento de explotación ya el 17 de octubre, cuatro días antes de los parches. Los parches se publicaron el miércoles con un poco de anticipación: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
La señal más elocuente: por la tarde, el Ministerio del Interior desconectó los sitios de todas las prefecturas a petición de la ANSSI, « mantenimiento preventivo de todos sus sitios web expuestos a una vulnerabilidad crítica de seguridad », y Météo-France cerró sus sitios de predicciones y alertas por su propia iniciativa. Parte del portal de impuestos también fue desconectada según la prensa, y al día siguiente la CAF (prestaciones familiares), Ameli (seguro de salud), la URSSAF y el CNES pasaron a mantenimiento a su vez, mientras Orange suspendía algunos sitios y aplicaciones de sus filiales. Países Bajos apagó DigiD y MijnOverheid, Finlandia sus servicios públicos en línea, consejos municipales británicos y servicios daneses hicieron lo mismo. Ninguno de estos sitios reportó intrusiones: es una medida de precaución, exactamente la que recomienda el CERT-FR cuando no se puede corregir de inmediato. Si el Estado corta sus propios sitios en lugar de asumir el riesgo, un sitio empresarial que funcione con PHP no tiene razón para creerse a salvo.
El punto que lo cambia todo: PHP 8.1, 8.0, 7.4 y versiones anteriores no recibirán nuevas versiones. El proyecto publicó parches de código fuente para 7.4, 8.0 y 8.1, que deben compilarse manualmente o obtenerse del proveedor de alojamiento, pero no habrá actualizaciones oficiales automáticas. Según W3Techs, aproximadamente uno de cada cuatro sitios en PHP aún funciona con PHP 7. Si ese es tu caso, nadie lo corregirá por ti.
El CERT-FR, el equipo de la ANSSI, publicó ese mismo día la alerta CERTFR-2026-ALE-014: aislar los sistemas afectados y luego migrar a una versión mantenida y corregida. Las soluciones alternativas que circulan, como desactivar session.upload_progress o bloquear el envío de archivos, reducen la superficie de ataque para una de las dos fallas. No sustituyen la actualización.
¿Qué es PHP2Shell? El sobrenombre dado a las dos fallas: una solicitud web especialmente estructurada permite ejecutar comandos en el servidor, un « shell », a través de PHP, sin necesidad de cuenta ni contraseña. No hay un virus llamado PHP2Shell que debas buscar en tu computadora. Es un defecto del motor PHP en sí, en el servidor, y se corrige con las versiones del 21 de octubre.
¿Qué versiones de PHP están corregidas?
El parche solo existe para las ramas que aún se mantienen. PHP 8.5 pasa a la versión 8.5.12, PHP 8.4 en 8.4.27, PHP 8.3 en 8.3.36 y PHP 8.2 en 8.2.35, y es la última rama corregida: finaliza el 31 de diciembre de 2026, por lo que el paso a 8.3 o 8.4 es inevitable antes de fin de año. PHP 8.1 está en fin de vida desde el 31 de diciembre de 2025, PHP 8.0 y 7.4 desde hace más tiempo: para estas tres, PHP ha publicado parches de código fuente para compilar por uno mismo, y algunos proveedores de alojamiento o distribuciones Linux los incluyen en sus paquetes. PHP 7.3 y versiones anteriores, PHP 5: nada, y watchTowr considera que todas las versiones desde PHP 5.4 están afectadas. Cambiar de rama es la única solución.
El número que importa es el que realmente usa tu sitio, no el de una línea de comandos en el servidor: un alojamiento puede ejecutar varias versiones simultáneamente.
Cómo verificar tu versión de PHP en OVH, o2switch, IONOS o Infomaniak
En WordPress o WooCommerce: Herramientas, luego Estado del sitio, pestaña Información, sección Servidor, línea «Versión de PHP». Actualizar WordPress, un tema o un plugin no cambia este número.
En o2switch: en cPanel, sección Software, la herramienta «Seleccionar una versión de PHP» muestra la versión actual en un menú desplegable. Elige 8.3 o 8.4 y luego «Aplicar», dejando marcadas las extensiones por defecto. Atención, la versión «nativa» seleccionada por defecto es PHP 8.1, que no recibe parches: el procedimiento completo y lo que hizo o2switch el 21 de octubre está en la guía de o2switch.
En OVHcloud: espacio del cliente, Web Cloud, Alojamientos, su alojamiento, pestaña Información general, línea « Versión global de PHP ». Para cambiar, en el apartado Configuración, el botón « … » y luego « Modificar la configuración ». Los más avanzados también pueden modificar la línea app.engine.version del archivo .ovhconfig en la raíz del FTP. El detalle, botón grisado y archivo .ovhconfig incluido, está en la guía de OVHcloud.
En IONOS: espacio del cliente, sección Alojamiento, menú PHP, « Abrir », marque el dominio, « Modificar la versión de PHP », elija y guarde. El cambio tarda unos minutos, y el ajuste es por dominio. El detalle, y qué significa el « PHP Extended Support » de IONOS, está en la guía de IONOS.
En Infomaniak: Manager, Alojamiento Web, haga clic en el nombre del producto, « Más información », « Modificar », elija la versión, « Guardar ». El cambio es inmediato, y volver a una versión vulnerable queda bloqueado después. Infomaniak también corrige por sí mismo PHP 7.4, 8.0 y 8.1, algo que casi ningún proveedor de alojamiento hace: el detalle hora por hora está en la guía de Infomaniak.
En Hostinger: hPanel, Sitios web, « Gestionar », luego « Configuración de PHP » bajo « Avanzado », elija la versión, « Actualizar ». La versión aplica a todos los sitios del plan, y Hostinger anuncia « ninguna acción requerida », lo que no cubre un sitio que permanezca en 8.1: la guía de Hostinger lo explica.
En PlanetHoster: en N0C, « Lenguajes », « PHP », elija la versión y luego « Aplicar »; en una cuenta antigua de cPanel o en HybridCloud, el camino cambia, y los envíos de archivos pueden devolver un error 403 esta noche debido a las medidas de emergencia del proveedor: todo está en la guía de PlanetHoster.
En un VPS, un servidor dedicado o Plesk: En Plesk, en la sección Sitios web y dominios, dentro del apartado PHP de cada sitio. En un servidor, el comando php -v muestra la versión en la línea de comandos, pero es la página phpinfo() o el encabezado X-Powered-By la que indica cuál es la versión que realmente sirve al sitio. Luego, con apt o dnf para actualizar, y reiniciar PHP-FPM o Apache.
En todos los casos, los números 8.2.35, 8.3.36, 8.4.27 y 8.5.12 son los que deben aparecer. La herramienta de verificación lee el número cuando el servidor lo muestra, y reconoce al proveedor de alojamiento para indicarte la ruta correcta.
¿Está afectado? Sitio, tienda, software, intranet
Se habla mucho de «sitios web», pero la vulnerabilidad no depende del nombre que se le dé. Lo que importa es lo que funciona en el servidor.
Su sitio web corporativo bajo WordPress, Joomla, Drupal, SPIP o TYPO3 funciona con PHP. Afectado.
Su tienda en línea bajo PrestaShop, WooCommerce, Magento o Thelia funciona con PHP. Afectada, y es el objetivo más interesante para un atacante: hay pagos y direcciones involucradas.
Su software empresarial, su intranet, su extranet, su espacio cliente, si han sido desarrollados en PHP (Laravel, Symfony o código propio), están afectados incluso si están protegidos con contraseña. La vulnerabilidad actúa antes de la página de conexión. Una herramienta interna que solo usan sus empleados, pero que es accesible desde internet, está expuesta como un sitio público.
Las herramientas instaladas en un servidor, como Dolibarr, GLPI, Nextcloud, Moodle, un foro phpBB, un wiki, una herramienta de tickets, están en la misma situación.
No afectados: los creadores de sitios como Wix, Squarespace, Shopify, Webflow, Jimdo o Google Sites. Ellos no ejecutan PHP por usted, y mantienen sus propios servidores. Una aplicación desarrollada en Node.js, Python o .NET tampoco está afectada por esta vulnerabilidad. Pequeña salvedad: Node.js publicó sus propios parches de seguridad el mismo día, el 21 de octubre. Mismo reflejo, mismo día.
Si no sabe en qué se basa su sitio, la herramienta de verificación lo detecta en su página de inicio: reconoce la plataforma, la versión de PHP cuando se muestra, y a menudo el proveedor de alojamiento. De lo contrario, la pregunta que debe hacerle a su proveedor de servicios es breve: «¿qué versión de PHP sirve a este sitio y ha sido actualizada desde el 21 de octubre?»
Lo que su proveedor de alojamiento hace, y lo que no hace
En alojamiento compartido (shared hosting), PHP pertenece al proveedor de alojamiento. No puedes instalarlo tú mismo; solo eliges una rama (8.1, 8.2, 8.3…) en tu espacio. El proveedor, por su parte, instala las versiones corregidas en sus servidores para las ramas aún mantenidas, desde 8.2 hasta 8.5.
El 21 de octubre por la noche, esto es lo que pude constatar. o2switch desactivó la funcionalidad en cuestión desde las 8:07 de la mañana, pero a las 16:40 sus servidores aún funcionaban con las versiones del 6 de octubre, esperando los paquetes de CloudLinux previstos para esa noche. OVHcloud anuncia reglas de firewall en sus clústeres compartidos y una campaña de mantenimiento. Infomaniak abrió una ventana de mantenimiento desde las 15:00 hasta las 3:00 del día siguiente, con los parches desplegados por sus equipos y sin acción adicional, excepto para los sitios que aún usaban una versión de PHP menos mantenida. Para IONOS, Hostinger, PlanetHoster, LWS o Gandi, no encontré ningún anuncio público a esa hora.
Esto es lo que le corresponde hacer en todos los casos: verificar en uno o dos días si la versión realmente ha cambiado. Un parche anunciado no es un parche instalado. Y si tu sitio usa PHP 8.1 o una versión anterior, el proveedor no lo actualizará: será tu responsabilidad pasar a 8.3 o 8.4 desde cPanel, Plesk o el espacio de cliente, después de hacer una copia de seguridad y probar, porque un tema antiguo o una extensión antigua podría no ser compatible.
Las tres preguntas que debe hacerle a su proveedor
Muchos sitios y herramientas fueron creados hace tres, cinco u ocho años por una agencia o un freelance con el que ya no se tiene contacto. Es el momento de escribirles, por correo electrónico, para dejar constancia.
Primera pregunta: ¿qué versión de PHP usa actualmente el sitio o la aplicación? La respuesta debe ser un número exacto, como 8.3.36, no «está actualizado».
Segunda pregunta: ¿ha sido actualizada desde el 21 de octubre de 2026, y por quién?
Tercera pregunta: ¿se han revisado los registros del servidor desde el 20 de octubre? Solicitudes POST masivas de tipo multipart hacia páginas que no las manejan son la señal a buscar.
Si nadie responde en el día o si el proveedor ya no existe, es exactamente el tipo de situación que yo manejo: recupero los accesos, actualizo, pruebo y le escribo sobre lo realizado.
¿Y si su sitio sigue funcionando con PHP 7 u 8.1?
Es el caso más delicado y el más frecuente entre las pequeñas y medianas empresas. Dos opciones.
El parche retroactivo: algunos proveedores de alojamiento y distribuciones Linux (Debian, Ubuntu) integran los parches en versiones antiguas sin cambiar el número. Hay que preguntarles, por escrito, si lo han hecho. Un número antiguo no prueba por sí solo la existencia de la vulnerabilidad, pero en caso de duda, se necesita confirmación.
Cambiar de rama: pasar a PHP 8.3 o 8.4. Es la solución real, y también lo que habrá que hacer de todos modos, ya que PHP 8.2 dejará de recibir soporte el 31 de diciembre de 2026. Requiere verificar que el CMS, el tema y las extensiones sean compatibles con la nueva versión, hacer una copia de seguridad fuera del servidor y probar en una copia antes de migrar. Una hora para un sitio sencillo, medio día para una tienda con muchos módulos.
Si ninguna de las dos opciones es posible hoy, la recomendación del CERT-FR es clara: ponga la aplicación fuera de línea o detrás de un firewall aplicativo, mientras se toman las medidas necesarias.
Impuestos, CAF, Ameli, prefecturas: ¿cuándo volverán y hay que preocuparse?
Si llegó aquí porque impots.gouv.fr o caf.fr muestra «en mantenimiento», porque su cuenta de Ameli no se abre o porque el sitio de su prefectura no responde: es esta falla, y es intencional. El Ministerio del Interior habla de una «puesta en mantenimiento preventivo» y de «lo antes posible» para el reinicio; la CAF habla de mantenimiento y mantiene sus plazos habituales de declaración. La vuelta se hace servicio a servicio: Météo-France reabrió el 22 de octubre por la mañana, ameli.fr y urssaf.fr respondían el 23 a las 11:40 (hora de París), y a la misma hora caf.fr, impots.gouv.fr y los sitios de las prefecturas seguían mostrando una página de mantenimiento. Sus datos no están en riesgo, no se ha anunciado ninguna intrusión, y no hay nada que hacer con estos sitios.
Solo una precaución: los correos electrónicos y SMS que afirman provenir de los impuestos, de su proveedor de alojamiento o de «ANSSI» para «verificar sus credenciales» florecerán en los próximos días. Las estafas siempre siguen este tipo de noticias.
Actualizar WordPress no es suficiente
Es la confusión que escucho con más frecuencia. «Hice las actualizaciones, todo está en verde». Las actualizaciones de WordPress, PrestaShop o los complementos no afectan a PHP, que funciona en segundo plano. Un complemento de seguridad puede bloquear ciertas solicitudes, pero no todas, y los atacantes ya han modificado sus cargas para pasar las reglas de Cloudflare. La única puerta que realmente cierra es la versión corregida de PHP en el servidor.
¿Cómo saber si ya es demasiado tarde?
Los primeros intentos de ataque los vio Amazon en sus señuelos ya el 17 de octubre, cuatro días antes del parche, y después de forma continua desde la mañana del 21. El 22, Wordfence veía los ataques continuar sin ninguna intrusión conocida por esta falla: tranquilizador, pero si su sitio permaneció expuesto, debe revisarlo.
En los registros de acceso del servidor, busque desde el 17 de octubre solicitudes POST de tipo multipart inusuales. En las carpetas de envío de archivos (uploads, cache, tmp), busque archivos .php recientes que no haya colocado allí. En la administración, busque cuentas administradoras desconocidas y tareas programadas nuevas. En caso de duda: copia de seguridad inmediata, cambio de todas las contraseñas de administración, y si se ven afectados datos personales de clientes, notificación a la CNIL en 72 horas.
Lo que puedo hacer por usted
Soy desarrollador freelance cerca de Rennes y trabajo a distancia en toda Francia. Para esta falla, hago algo sencillo: leo la versión de PHP realmente servida por su sitio, su tienda o su herramienta, actualizo PHP o cambio de rama, verifico que todo siga funcionando y le escribo lo que se ha hecho. Si su proveedor de servicios no responde, recupero los accesos y retomo el trabajo.
Comience por verificar su sitio gratuitamente, tarda diez segundos. Y si el resultado no es el que esperaba, escríbanme: respondo en menos de 24 horas.
Fuentes: avisos de seguridad y versiones corregidas en php.net, alerta CERTFR-2026-ALE-014 del CERT-FR, prefecturas y Météo-France fuera de línea, France 3 el 21 de octubre a las 18:56, sitios públicos caídos en Países Bajos, Finlandia y Reino Unido, según The Record, reglas de firewall de Cloudflare, lista de proveedores de alojamiento por Clubic el 21 de octubre a las 18:25, página de estado de Infomaniak, parches de seguridad de Node.js del 21 de octubre de 2026, intento de explotación del 17 de octubre visto por Amazon, Ameli, CAF, impuestos y URSSAF fuera de servicio, Clubic el 22 de octubre a las 10:53, ataques en curso sin intrusión conocida, Wordfence el 22 de octubre.
