Dos fallos con CVSS 9,2 que no pasan por tu pantalla de login
El 21 de octubre el equipo de PHP publicó parches de emergencia para CVE-2026-109618 y CVE-2026-109619, dos vulnerabilidades bautizadas como PHP2Shell y puntuadas con 9,2 sobre 10 en CVSS 4.0. Ambas permiten ejecución remota de código sin autenticación: un atacante sin cuenta ni contraseña puede llegar a ejecutar código en tu servidor.
Para un founder esto no es una nota de infraestructura ajena. Censys estimó en un escaneo reciente unos 2,58 millones de hosts expuestos a internet y 54,9 millones de propiedades web corriendo PHP, según reportó Krebs on Security. Y W3Techs calcula que PHP está detrás del 69,3% de los sitios cuyo lenguaje de servidor se puede identificar, incluido todo WordPress, según The Verge.
¿Por qué no te protege tener WordPress y los plugins al día?
Porque el fallo no está en tu aplicación, sino en el intérprete que la ejecuta. PHP procesa cada petición antes de que tu código —WordPress, Laravel o un desarrollo propio— haga nada. Actualizar el CMS no actualiza el motor: ese llega del paquete del sistema operativo, del proveedor de hosting o de la imagen del contenedor.
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 díasWiz lo resume con un ejemplo incómodo: incluso una aplicación mínima tipo «Hello World» es vulnerable si corre sobre una versión afectada. Y no es un nicho: el aviso oficial de PHP identifica como afectadas todas las instalaciones que sirven peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
El escenario de mayor riesgo es Apache con mod_php, donde una sola petición sin autenticar desencadena el ataque antes de que se ejecute el código de la aplicación. Tu contraseña robusta y tu segundo factor no llegan a entrar en juego.
¿Qué puede hacer un atacante con un servidor sin parchear?
Tres cosas, de peor a menos mala, y ninguna requiere usuario ni contraseña:
- Ejecución remota de código. Wiz demostró ataques sin autenticación contra las imágenes de contenedor más recientes de WordPress, Drupal y Joomla. El acceso resultante es el del proceso que atiende las peticiones, suficiente para robar datos, desfigurar el sitio o instalar un web shell.
- Lectura de memoria del proceso. Sin llegar a ejecutar código, un atacante puede leer trozos de memoria que, según Wiz, pueden contener contraseñas, tokens de autenticación, claves de API y certificados de otras peticiones o del propio servidor. Wiz la sitúa en la línea de Heartbleed y asegura que la fuga funciona sea cual sea la aplicación.
- Caída del servicio. Cloudflare explicó que el mismo mecanismo puede tumbar procesos de PHP: menos grave, pero suficiente para dejar una tienda sin vender.
El NCSC británico añade un detalle que cambia la urgencia: si no puedes actualizar ya, revisa el sistema en busca de puertas traseras. Parchear tarde no limpia lo que alguien haya dejado dentro.
¿Se está atacando ya o es solo teoría?
Hay intentos de ataque documentados y ninguna intrusión confirmada públicamente a fecha de publicación. La ventana entre el parche y los ataques fue mínima porque la información se filtró antes de tiempo: según la PHP Foundation, el 20 de octubre hacia las 15:00 UTC los dos identificadores empezaron a circular por foros y redes con una hora de publicación y una puntuación de 10 que eran falsas. PHP adelantó el lanzamiento un día, al 21 de octubre a las 14:00 UTC.
Cloudflare desplegó reglas de WAF desde las 3:02 UTC del 21 de octubre, también en el plan gratuito, y su CTO Dane Knecht confirmó que ya observaba tráfico de ataque contra clientes, con atacantes modificando la carga para esquivar reglas. La firma Sansec advirtió, según SecurityWeek, que la explotación masiva probablemente empezaría en los 15 minutos siguientes a la publicación del parche.
Algunas organizaciones no esperaron: en Países Bajos, DigiD y MijnOverheid se desconectaron como precaución, y la empresa de nóminas BambooHR apagó su servicio en Estados Unidos, Canadá e Irlanda. El investigador Kevin Beaumont lo calificó como «una de las mayores vulnerabilidades en años».
¿Qué pasa si tu versión de PHP ya no recibe actualizaciones?
El riesgo es el mismo, pero la solución oficial no llega sola. PHP 8.1 y anteriores ya no reciben parches del proyecto, y PHP 8.2 deja de tenerlos el 31 de diciembre de 2026. El equipo de seguridad publicó parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1, pensados para quien compila PHP. El resto depende de su distribución o de un proveedor de soporte extendido, que recibieron el parche por adelantado.
Ojo con un detalle práctico: un paquete de distribución puede llevar la corrección con un número de versión que parece antiguo. Lo que hay que comprobar es que el registro de cambios mencione los dos CVE.
Las mitigaciones temporales existen —fijar memory_limit=-1, bajar post_max_size a 8M (o 32M si hay subidas de archivos), desactivar session.upload_progress.enabled y, en PHP 8.5, fatal_error_backtraces=0— pero el aviso oficial es tajante: reducen la exposición a rutas de ataque concretas y no hacen segura una instalación. La desarrolladora del núcleo Gina Peter Banyard lo dijo antes del parche: la única mitigación es actualizar PHP.
¿Qué significa esto para tu startup?
Tres acciones concretas, en orden de urgencia:
- Averigua qué versión de PHP responde de verdad. No la del panel de hosting, la que ejecuta el proceso. Si estás en 8.2.35, 8.3.36, 8.4.27 o 8.5.12 o superior, ya tienes el parche.
- Si usas hosting gestionado, exige confirmación por escrito. Que te digan en qué versión quedó el runtime y cuándo se reiniciaron los workers. Actualizar el paquete sin reiniciar Apache, PHP-FPM y los procesos de larga duración deja el código viejo corriendo.
- Si estás en PHP 8.1 o anterior, decide hoy. No habrá parche oficial del proyecto. Las opciones son migrar a una versión soportada, contratar soporte extendido con tu proveedor o, si el sistema no es crítico, apagarlo. El NCSC va más allá: si no puedes actualizar ni mitigar a tiempo, plantéate desconectar el sistema.
Y una cuarta, si guardas datos de usuarios: busca indicios de intrusión previa. Peticiones multipart inusuales seguidas de errores de límite de memoria o de HTTP 500 repetidos, cookies PHPSESSID anormalmente grandes y reinicios inexplicables de procesos de PHP. Wiz avisa de que, como el ataque ocurre por debajo de la aplicación, los registros de la web aportan poco contexto.
El parche cambia el comportamiento de tu servidor
El arreglo añade un límite de memoria estricto: si se alcanza, el proceso termina. Conviene revisar memory_limit y post_max_size contra lo que necesita tu aplicación para no provocar caídas propias justo después de actualizar. Es un detalle que se pasa por alto y que puede convertir una victoria de seguridad en un incidente de disponibilidad.
Lo que este episodio dice sobre el costo de la IA ofensiva
Wiz encontró su primer fallo el 19 de agosto con su herramienta Wiz Atlas y los modelos Gemini 4 Argon y GPT-5.6 Sol, y sostiene que con IA frontera un solo investigador hizo en una semana lo que antes habría llevado meses a un equipo de primer nivel. OpenAI, que participó en la investigación, calificó el caso como «uno de los problemas de seguridad más impactantes de la memoria reciente».
La propia PHP Foundation reconoce que vio las primeras señales del problema de memoria en 2024 y que el arreglo se atascó durante meses; lo califica de «fallo estructural». Desde el 1 de julio ha publicado 15 CVE y descartado más de 100 informes inválidos, duplicados o no reproducibles.
Conclusión
El cálculo del webmaster cambió. Durante años, «actualizo PHP cuando cambio de hosting» era una apuesta razonable porque explotar fallos de memoria así exigía un talento escaso. Si la IA abarata ese trabajo, el tiempo entre parche y ataque se mide en horas. Una web con todo al día salvo el intérprete no es una web segura: es una web con la puerta blindada y los cimientos abiertos.
Fuentes
- wwwhatsnew: PHP2Shell, qué le puede pasar a tu web si no actualizas PHP (fuente original)
- Help Net Security: PHP2Shell, critical PHP vulnerabilities patched
- Krebs on Security: Widespread PHP Flaw May Cause Many Site Outages Today
- The Verge: PHP, the three letters that shut down sites all over the internet today
- BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
- SecurityWeek: Mass Exploitation Looms for Leaked Critical PHP Flaws
- Hackread: PHP Releases Emergency Fixes for Critical PHP2Shell Vulnerabilities
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
