PHP2Shell: qué es el fallo de PHP de esta semana y qué hacer si tu web corre en PHP
· 6 min de lectura
El miércoles 21 de octubre el equipo de PHP publicó actualizaciones de emergencia para dos fallos de seguridad críticos, bautizados PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Los dos permiten que alguien, desde internet y sin usuario ni contraseña, ejecute código en el servidor con los permisos del proceso web. En la práctica, eso es tomar el control de la aplicación y de lo que ella pueda leer: la base de datos, los archivos subidos, las claves de las integraciones.
PHP está detrás de la mayoría de los sitios web cuyo lenguaje de servidor se conoce: W3Techs lo sitúa en el 69,3%. Ahí entran WordPress, WooCommerce, Drupal, Joomla, Magento y buena parte de los sistemas a medida hechos con Laravel o Symfony. Si tu negocio tiene una web, es bastante probable que esto te toque.
Qué pasó, en limpio
Son dos errores distintos en el corazón de PHP, no en un plugin ni en un framework. El primero (CVE-2026-109618) aparece cuando un pedido agota la memoria en un momento delicado: PHP corta a medias y, al limpiar, trata como válidos datos que nunca terminó de preparar. El segundo (CVE-2026-109619) es un resto de un pedido anterior que queda apuntando a memoria ya liberada y que el siguiente pedido, atendido por el mismo proceso, puede aprovechar. Los dos tienen una puntuación de 9,2 sobre 10 en la escala CVSS 4.0; las cifras de 10 que circularon al principio fueron un error, según la PHP Foundation.
Lo que los vuelve serios es el alcance. Afectan a todas las formas habituales de servir PHP —PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed— y el código vulnerable más antiguo que se encontró viene de PHP 5.4, de 2012. El propio equipo de PHP señala a Apache con mod_php como el caso de mayor riesgo, porque el ataque demostrado ocurre antes de que se ejecute una sola línea de la aplicación: no importa qué tan bien esté escrito tu WordPress o tu sistema.
Ya hay intentos de ataque
La publicación estaba prevista para el 22 de octubre y se adelantó un día porque los identificadores de los fallos se filtraron el 20. Pero los ataques empezaron antes: Amazon detectó un primer intento en su red de señuelos el 17 de octubre, cuatro días antes del anuncio, y el 21 vio más intentos con indicios de varios atacantes distintos. Cloudflare y watchTowr también informan intentos de explotación.
Hay matices, y conviene no exagerar. Al 22 de octubre, Rapid7 revisó las pruebas de concepto públicas y concluyó que cada una funciona sólo contra una combinación concreta de sistema operativo, versión de PHP y servidor web; ninguna es un ataque general y confiable. Eso no es motivo para esperar: es la ventana para actualizar antes de que alguien la cierre. Y un aviso práctico: hay código que dice explotar estos fallos circulando por ahí, sin verificar, y puede traer malware.
Actualizar es la única solución completa. Todo lo demás reduce el riesgo, pero no lo elimina.
Qué versiones están corregidas
Las versiones seguras son 8.5.12, 8.4.27, 8.3.36 y 8.2.35 o posteriores, cada una en su rama. Cualquier versión anterior de esas ramas es vulnerable. Las distribuciones de Linux y los proveedores con soporte extendido recibieron los parches por adelantado, así que si PHP viene de los paquetes del sistema, lo correcto es aplicar la actualización del propio proveedor.
El problema está en las versiones viejas. Para PHP 7.4, 8.0 y 8.1 —ya sin soporte— el equipo de PHP sólo publicó parches en código fuente, sin versiones listas para instalar. Para todo lo anterior a 7.4 no hay arreglo. Si tu sitio corre en una de esas versiones, este fallo no se resuelve con un parche: se resuelve migrando a una versión soportada, que es lo que había que hacer de todas formas.
Qué hacer hoy, según cómo esté alojada tu web
Si tenés hosting compartido o administrado (lo típico de un WordPress en Hostinger, SiteGround, GoDaddy o similares), no controlás la versión de PHP del servidor: la controla el proveedor. Escribile hoy y preguntá algo concreto: si ya aplicaron los parches de PHP2Shell y en qué versión quedó tu sitio. Muchos paneles muestran la versión de PHP; si la tuya es 8.1 o anterior, pedí el cambio a una soportada y probá el sitio después.
Si tenés un servidor propio (un VPS, un contenedor, un equipo en la oficina), te toca a vos o a quien te lo administra: actualizar PHP a la versión corregida de su rama y reiniciar todos los procesos de PHP, porque los que siguen corriendo conservan el código viejo en memoria. Revisá también las imágenes de Docker: una imagen construida la semana pasada trae la versión vulnerable aunque el servidor esté al día.
Si no podés actualizar hoy, hay medidas que reducen la exposición mientras tanto. Las publicadas por el equipo de PHP son fijar memory_limit=-1 de forma que la aplicación no pueda cambiarlo, desactivar session.upload_progress.enabled y, en PHP 8.5, desactivar fatal_error_backtraces, siempre desde la configuración del servidor y reiniciando los procesos después. Cloudflare activó reglas de su firewall para los ataques conocidos, incluso en el plan gratuito, pero sólo protegen el tráfico que pasa por Cloudflare. Ninguna de estas medidas reemplaza la actualización: tocan límites de memoria y de subida de archivos, así que conviene que las aplique alguien que sepa qué está cambiando. Sobre todo la primera: sin límite de memoria, un pedido pesado puede agotar la RAM de todo el servidor y tirar también la base de datos; en un servidor chico, ese es un riesgo en sí mismo.
Y después de actualizar, mirá para atrás. Amazon recomienda revisar la actividad desde el 17 de octubre. Un parche cierra la puerta, pero no te dice si alguien entró antes: archivos nuevos o modificados en el servidor, usuarios administradores que nadie creó, tareas programadas desconocidas o tráfico saliente raro son señales para investigar. Que no haya nada en los logs no prueba que no haya pasado nada.
Lo que deja esta semana
Un dato de este caso merece atención: los equipos que encontraron los fallos dicen haber usado modelos de IA en su investigación. Código que llevaba más de una década en producción, revisado por miles de personas, apareció ahora. Es razonable esperar que esto se repita, y que los que buscan fallos para atacar usen las mismas herramientas.
La consecuencia práctica no es el pánico, es el mantenimiento. Los sitios que mejor pasan una semana como esta son los que ya corrían una versión soportada, tenían a alguien con acceso y criterio para actualizar el mismo día, y un cliente que sabía a quién llamar. Los que peor la pasan son los que nadie toca desde que se entregaron, en un PHP 7 que nadie se animó a migrar, con un proveedor que ya no contesta. Por eso insistimos en que las cuentas y los accesos sean del cliente: cuando hay que actuar rápido, no se puede depender de encontrar a quien tiene la llave.
Si no sabés en qué versión de PHP corre tu web, o no tenés claro quién se ocupa de actualizarla, ese es el primer problema a resolver, antes que este fallo y antes del próximo.