PHP2Shell: dos fallos críticos de PHP que dejan a los hackers tomar el control de servidores web

Si tienes una web o un servidor con PHP, deja de leer un segundo y ve a actualizarlo. En serio.

El 21 de octubre el equipo de PHP publicó actualizaciones de emergencia para dos fallos críticos, apodados PHP2Shell. Con ellos, un atacante puede ejecutar su propio código en tu servidor web solo con mandarle una petición preparada a propósito. Sin contraseña, sin cuenta, sin hacer clic en nada. Una sola petición y el servidor es suyo.

Y PHP está en todas partes: WordPress, Drupal, Joomla, montones de paneles de control de hosting… así que esto es gordo.

Qué pasó

Los fallos los encontraron los investigadores de Wiz, que se los comunicaron a PHP el 24 de agosto. Los dos son fallos de memoria llamados use-after-free (uso después de liberar): PHP tira un trozo de memoria pero luego lo sigue usando. Es como tirar una página de un libro a la papelera y luego intentar seguir leyéndola, solo que un atacante puede escribir en esa página a escondidas antes. Así es como toman el control.

• CVE-2026-109618 está en cómo gestiona PHP quedarse sin memoria y el progreso de subida de archivos. Wiz también lo usó para sacar memoria del servidor.
• CVE-2026-109619 está en cosas que PHP guarda entre peticiones, como la gestión de errores fatales y OPcache.

Wiz enseñó ataques que funcionaban contra webs de WordPress, Drupal y Joomla sin iniciar sesión. Y aquí viene lo fuerte: dicen que los modelos de IA les ayudaron a convertir estos fallos viejos y difíciles de explotar en ataques que funcionan. Eso es genial para que los buenos encuentren fallos más rápido… pero los malos tienen las mismas herramientas de IA.

¿Cómo de grave es comparado con otros fallos famosos?

Para ponerlo en perspectiva, así se compara con dos de los fallos de internet más famosos de la historia:

En mi opinión no es tan grave como Log4Shell. Aquel estaba escondido dentro de miles de programas de Java y mucha gente ni sabía que usaba Log4j. Aquí al menos sabes si usas PHP. Pero PHP mueve una parte enorme de la web, así que el número de servidores expuestos es gigantesco, y muchas webs pequeñas nunca se actualizan.

¿Me afecta?

Si tu servidor usa PHP para responder a peticiones web, da por hecho que sí. Da igual cómo esté montado: Apache con mod_php (el que más riesgo tiene), PHP-FPM (Nginx y la mayoría de hostings), php-cgi, LiteSpeed o FrankenPHP. Y los fallos vienen de hace años, así que las versiones antiguas también están afectadas.

En 8.1, 8.0 o 7.4 solo puedes conseguir el arreglo de tu distribución de Linux o de tu proveedor de hosting. En 7.3 o anteriores no hay arreglo ninguno, así que toca actualizar.

¿Lo están usando ya los hackers?

Depende de a quién preguntes. La empresa de seguridad watchTowr dice que ha visto ataques contra sus honeypots (servidores falsos para pillar hackers) desde el 21 de octubre, el mismo día que salieron los parches. La agencia estadounidense CISA dijo en su alerta que todavía no había visto ataques con éxito. En cualquier caso, los detalles ya son públicos, así que es cuestión de tiempo. Trátalo como algo urgente.

Qué deberías hacer

1. Mira tu versión de PHP. En el servidor ejecuta php -v. Para ver la versión que usa de verdad tu web, mira el panel de tu hosting, o crea una página con <?php phpinfo(); ?> (¡y bórrala justo después!).
2. Actualiza. En Debian o Ubuntu: sudo apt update && sudo apt upgrade, y luego reinicia tu servidor web o PHP-FPM. En un hosting compartido, comprueba que tu proveedor ya lo ha actualizado, o elige una versión arreglada en el panel.
3. ¿Todavía no puedes actualizar? Desconecta la web o limita quién puede llegar a ella. Un firewall web (Cloudflare y otros ya tienen reglas para esto) ayuda mientras tanto, pero no es un arreglo de verdad. El propio PHP dice que ningún ajuste te protege del todo.
4. Vigila señales de ataque: muchos errores 500, errores de “memory limit”, cookies PHPSESSID raras o enormes, procesos de PHP que se cuelgan y se reinician, o PHP abriendo shells y descargando archivos.

Cronología

• 19 ago 2026Wiz encuentra el primer fallo
• 20–21 agoSe confirma la ejecución remota de código en Drupal y WordPress
• 24 agoSe comunican los fallos al equipo de seguridad de PHP
• 21 sepPHP lo confirma y empieza a trabajar en un arreglo
• 21 octSalen los parches y se publican los detalles. watchTowr informa de los primeros ataques
• 23 octCISA actualiza su alerta con reglas de detección