Hoy, 21 de octubre de 2026, el equipo de seguridad de PHP ha publicado un aviso de emergencia: dos vulnerabilidades críticas en el propio núcleo del lenguaje, bautizadas colectivamente como PHP2Shell, permiten a un atacante ejecutar código de forma remota y sin autenticación en cualquier servidor que sirva PHP por web. No es un fallo de WordPress, ni de un plugin, ni de una mala configuración tuya: está en el intérprete.

La gravedad máxima viene de un detalle técnico importante: la petición maliciosa se procesa antes de que se ejecute una sola línea de tu código. Da igual lo bien escrita que esté tu aplicación — login, validaciones, WAF de aplicación — porque el ataque ocurre dentro del propio PHP mientras prepara la petición.

Las dos nuevas entradas en CVE

Ambas comparten la misma causa raíz — PHP puede dejar su memoria en un estado corrupto cuando una petición termina de forma anómala — pero se explotan por caminos distintos. Cada una tiene una puntuación CVSS 9.2 (crítica):

  • CVE-2026-109618 — La gestión de errores de falta de memoria (OOM) puede interrumpir PHP mientras los datos internos de la petición están solo parcialmente inicializados. La limpieza posterior de la petición trata esos datos inválidos como válidos, lo que desemboca en corrupción de memoria y ejecución remota de código con los privilegios del worker web.
  • CVE-2026-109619 — El estado interno propiedad de una petición puede sobrevivir después de que su memoria haya sido liberada. Una petición posterior atendida por el mismo worker puede usar ese estado obsoleto antes de que la inicialización normal lo resetee: use-after-free en el heap, divulgación de memoria y, de nuevo, ejecución remota de código sin autenticación.

Afectan a todas las instalaciones de PHP que sirven peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El equipo de PHP considera el riesgo más alto en mod_php, donde ya existe un exploit demostrado que se dispara antes de que corra el código de la aplicación.

Páginas afectadas

Hemos auditado toda nuestra infraestructura y estas son las páginas que sirven PHP con versiones por debajo de las parcheadas — es decir, vulnerables hasta que se aplique la actualización:

  • PHP 8.3.35 (vulnerable, requiere 8.3.36): www.io-backup.com, www.dynamicdnspro.com, www.fisem.com.
  • PHP 8.4.25 (vulnerable, requiere 8.4.27): www.emhaseasociados.es, app.emhaseasociados.es.
  • PHP 8.4.26 (vulnerable, requiere 8.4.27): scanner.net-analyzer.com, app.fisem.com, buy.dynamicdnspro.com.

Si administras tus propios sitios, puedes comprobar la versión que expone cada uno con curl -sI https://tudominio.com | grep -i x-powered-by. Ojo: que la cabecera no aparezca no significa que estés a salvo, solo que el servidor no la anuncia.

Medidas urgentes

El único arreglo completo es actualizar PHP. Las versiones con el parche son:

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Para PHP 8.1 y anteriores — fuera de soporte — el equipo de PHP ha publicado backports mínimos para 7.4, 8.0 y 8.1, pero la recomendación oficial es migrar a una rama soportada. Mientras tanto, estas son las medidas que estamos aplicando y que recomendamos:

  1. Actualizar cuanto antes a la versión parcheada de tu rama, priorizando los servidores expuestos a Internet.
  2. Mitigación parcial inmediata: desactivar session.upload_progress.enabled=0 en php.ini y, en PHP 8.5, también fatal_error_backtraces=0. Reinicia todos los workers tras el cambio. Ojo: según los análisis de Datadog y JFrog esta mitigación es parcial, no completa — no sustituye al parche.
  3. Fijar memory_limit=-1 en lugar de usar límites RLIMIT, para reducir los caminos de corrupción por OOM.
  4. Filtrar en el borde: un WAF o proxy inverso delante de PHP puede bloquear las peticiones multipart anómalas antes de que lleguen al parser vulnerable.
  5. Monitorizar: revisa logs buscando envíos de formularios muy grandes, errores de agotamiento de memoria durante la inicialización de peticiones y procesos shell inesperados lanzados por los workers de PHP.

Si no puedes actualizar de inmediato, CISA recomienda incluso sacar de línea los sistemas PHP expuestos hasta que puedan parchearse. Es una recomendación drástica para una vulnerabilidad drástica.

Conclusión

PHP2Shell es de los fallos que solo aparecen una vez cada varios años: crítico, sin autenticación y en la capa que está por debajo de cualquier aplicación. El parche ya existe y aplicarlo es cuestión de minutos en la mayoría de sistemas. Nosotros ya estamos actualizando todas las páginas afectadas listadas arriba; si tienes cualquier sitio servido con PHP, este es el momento de hacer lo mismo.