PHP2Shell: Una vulnerabilidad de hace años, una emergencia global y qué hacer ahora
Un fallo de memoria se detectó por primera vez en PHP en 2024. Pasaron dos años sin solución. Después, la investigación asistida por IA lo convirtió en un exploit funcional. Ahora, más de 22,6 millones de casos expuestos a Internet están potencialmente en riesgo. Actualmente, los atacantes están sondeando servidores vulnerables, y los sitios web públicos de toda Europa quedaron fuera de servicio mientras Teams actualiza los parches.
El encriptación se remonta a dos fallos críticos en PHP, conocidos juntos como PHP2Shell. El 21 de octubre, los desarrolladores de PHP lanzaron parches tanto para CVE-2026-109618 como para CVE-2026-109619, cada uno con un puntaje de 9,2 sobre 10 en gravedad. PHP alimenta aproximadamente el 70% de los sitios web que usan una tecnología de programación conocida en el lado del servidor, incluyendo sitios construidos en WordPress, Drupal y Joomla. Y como los fallos están en PHP en sí y no en un plugin o app, los atacantes podrían ejecutar código malicioso sin iniciar sesión. Desde ahí, podrían tomar el control de un servidor vulnerable o extraer datos sensibles directamente de su memoria.
PHP2Shell es más que un problema de parcheo. La investigación asistida por IA puede convertir fallos antiguos en exploits funcionales más rápido de lo que los equipos pueden probar y enviar soluciones. Y un servidor sitio web público vulnerado puede dar a los atacantes un camino hacia bases de datos, aplicaciones internas y cargas de trabajo en la nube. El parcheo debe venir con un segundo plan: ver esos caminos, limitar el movimiento lateral y contener un incumplimiento antes de que se extienda.
"Es casi como si alguien encontró una llave universal para todas nuestras puertas principales", dijo Christer Swartz, director de soluciones industriales de Illumio.
La carrera para parchear comenzó con una fuga. El 20 de octubre, los dos identificadores CVE comenzaron a circular en línea. PHP adelantó su lanzamiento un día. Esa noche, la compañía de seguridad Calif publicó por error un video de un exploit funcional. Copias que se difunden en las redes sociales. A la mañana siguiente, Chainguard publicó imágenes de software con la corrección más de seis horas antes del lanzamiento coordinado. Los atacantes podían estudiar la solución antes de que la mayoría de los equipos tuvieran oportunidad de parchear.
Las consecuencias llegaron rápidamente a los servicios públicos. Agencias gubernamentales, universidades y otros sitios web públicos de toda Europa se desconectaron mientras los equipos se apresuraban a aplicar parches. Las agencias de seguridad pidieron actualizaciones inmediatas. Cloudflare vio tráfico de ataque contra sus clientes antes de que se enviaran los parches. Amazon Amenaza Intelligence afirma detectar un intento de explotación el 17 de octubre, cuatro días antes de que los fallos se hicieran públicos. Ahora informa de una explotación generalizada en estado salvaje. Aún no está claro cuántos intentos tuvieron éxito.
La advertencia que quedó sin resolver
El tiempo empezó mucho antes de que el público conociera PHP2Shell.
En 2024, un desarrollador de PHP detectó los primeros signos del problema de memoria mientras solucionaba un problema diferente de una auditoría de seguridad. El equipo sopesó varias correcciones. Cada uno suponía el riesgo de romper la compatibilidad, crear nuevos riesgos de denegación de servicio o forzar cambios en extensiones de terceros. Sin una ruta conocida para la ejecución remota del código, el trabajo se estancó.
Entonces las apuestas cambiaron.
En agosto, una investigación asistida por IA mostró lo que podía hacer la falla. El 11 de agosto, investigadores de California y OpenAI informaron por separado de una ruta remota de ejecución de código con la misma causa raíz. Días después, Wiz empleó modelos de IA de frontera para encontrar más rutas de ataque. Su equipo mostró ataques efectivos contra sitios de WordPress, Drupal y Joomla. El error ahora era una vía de acceso a un servidor sitio web en activo.
El equipo de PHP y los investigadores comenzaron a trabajar en parches. Su objetivo era dar tiempo a los propietarios de los sitios para preparar. Pero el plan se vino abajo cuando se filtraron detalles antes de la publicación.
El camino desde la advertencia hasta la crisis
- 2024: Al corregir un hallazgo de auditoría, un desarrollador de PHP detecta la falla de memoria. Un arreglo se estanca.
- Agosto de 2026: California, OpenAI y Wiz emplean investigaciones asistidas por IA para mostrar la ejecución remota de código.
- Agosto a octubre de 2026: Los mantenedores e investigadores de PHP trabajan en una solución para una versión del 22 de octubre.
- 17 de octubre: Amazon detecta un intento de exploit en un honeypot.
- 20 de octubre: La filtración de identificadores CVE. PHP adelanta el lanzamiento un día. Calif publica un video de exploit por error.
- 21 de octubre: Chainguard publica imágenes fijas anticipadamente. PHP lanza parches cuando los sitios web se desconectan y los intentos de explotación disparan.
Desde entonces, la Fundación PHP reconoció lagunas en cómo gestionó la antigua advertencia. Su relato también muestra lo difícil que es mantener una solución en secreto una vez que se extiende la prueba de un exploit. Un parche necesita pruebas. Los atacantes solo necesitan un servidor que aún no fue parcheado.
No todos los sitios de PHP enfrentan el mismo riesgo. El riesgo depende de la versión que se use, la configuración del servidor y los controles que la rodean. Pero la crisis puso un límite severo al tiempo que los equipos tenían para actuar.
Un servidor sitio web puede ser un camino hacia la red
Piensa en un portal de clientes. Puede conectarse a una base de datos para registros de cuentas, una API para pagos y aplicaciones en la nube para otras tareas. Esos enlaces permiten que el sitio funcione. También pueden dar a un intruso una ruta más allá de la puerta principal.
Swartz advirtió que un atacante que toma el control de un servidor sitio web puede seguir los caminos que ya emplea la aplicación.
"Y si esta amenaza llega a un servidor sitio web orientado al cliente ... y no puedes detectarlo, simplemente empezará a seguir los mismos caminos cada vez más profundos en tu red que dejaste abierta", dijo.
El atacante puede buscar claves API o tokens de inicio de sesión en la memoria del servidor. Wiz demostró que estos fallos pueden filtrar exactamente ese tipo de datos. El atacante también podría probar a qué sistemas puede llegar el servidor. Si el acceso es demasiado amplio, un incumplimiento podría poner en riesgo los datos de los clientes, las aplicaciones internas y los activos críticos.
El estado del parche por sí solo no te dice hasta dónde puede llegar eso. Los equipos también necesitan saber a qué puede llegar un servidor después de que sea vulnerado.
Eso incluye cualquier vínculo entre TI y tecnología operativa (OT), donde un camino mal asegurado podría exponer los sistemas de la planta.
La IA cambió el ritmo de la carrera
La IA ayudó a los investigadores a descubrir el riesgo. Eso dio a los defensores la oportunidad de arreglarlo. Pero las mismas herramientas pueden ayudar a los atacantes a encontrar formas de acceder.
Swartz ve un nuevo problema para los equipos que dependen de la respuesta manual.
"Diría que lo que significa para la ventana de vulnerabilidad es que ahora es mucho más corta de lo que cualquier humano puede responder", dijo. Fue más directo sobre el costo del retraso: "Si dependes de una persona... un humano escribiendo en un teclado, perdiste."
El problema es la velocidad. Los analistas aún necesitan evaluar riesgos e investigar los ataques. Pero para cuando alguien detecta una conexión desconocida y actúa en consecuencia, el atacante puede pasar página.
Cómo limitar el daño
1. Empiece con los servidores expuestos
El primer paso es encontrar los servidores PHP afectados y aplicar las actualizaciones de seguridad. Si un servidor público no puede ser parcheado, restringir el acceso o desconectarlo puede ser la opción más segura.
Swartz clasificaría el trabajo por exposición, no solo por el número de servidores. Un sitio vinculado a una base de datos sensible u otro activo crítico merece una atención muy detallada.
"Tienes que hacer parches, pero también tienes que preguntar a qué puede llegar ese servidor", dijo. "Si se conecta a activos críticos, el riesgo es mucho mayor que la vulnerabilidad de esa única máquina." Para sitios balanceados en carga, recomienda parchear un grupo de servidores mientras los demás mantienen el sitio en funcionamiento. Entonces los equipos pueden cambiar el tráfico y parchear el resto.
2. Ver hacia dónde podría ir un atacante a continuación
La siguiente preocupación de Swartz son los enlaces del servidor sitio web a APIs, bases de datos, aplicaciones internas y cargas de trabajo en la nube. Esos caminos suelen tener sentido para el negocio. También pueden convertir en rutas para el movimiento lateral.
"Si no sabes con qué sistemas comunica tu servidor sitio web, no sabes hasta dónde podría llegar un atacante", dijo. "Primero mapea esas conexiones. Así podrás ver cuáles deben estar ahí y cuáles ponen en riesgo activos críticos."
3. Vigilar los cambios en el tráfico
También buscaría tráfico que rompa el patrón normal de un servidor: nuevas conexiones de carga de trabajo, destinos extraños o un aumento repentino de volumen.
Puso DNS como ejemplo. Un servidor que normalmente envía pequeñas solicitudes DNS pero empieza a mover grandes cantidades de datos puede necesitar una revisión más detallada. No es un afiche específico de PHP2Shell, y no prueba un incumplimiento. Para PHP2Shell, Wiz sugiere vigilar solicitudes de subida inusuales seguidas de errores en el límite de memoria o respuestas repetidas HTTP 500.
"Puede que no sepas qué vulnerabilidad usó un atacante", dijo. "Pero aún puedes imaginar una carga de trabajo haciendo algo que nunca hizo antes. Ese es el tipo de cambio que tienes que captar antes de que el ataque se extienda."
4. Cortar caminos innecesarios
"La mejor práctica, diría yo, es segmentar tus aplicaciones independientemente de los segmentos subyacentes", dijo Swartz. En otras palabras, establece controles alrededor de cada app, sea cual sea la red en la que esté ubicada.
Sostiene que un firewall en el edge, una VLAN o un límite de red en la nube no siempre controlan el acceso entre aplicaciones. La segmentación a nivel de carga de trabajo puede restringir a cada servidor a los servicios que necesita.
"Un servidor sitio web puede necesitar comunicar con una sola base de datos", dijo. "Eso no significa que deba poder acceder a todas las bases de datos. Si el servidor se ve comprometido, esos límites pueden impedir que el atacante lo emplee como puente hacia el resto de la red."
5. Asumir que el parche puede no ser el final
Swartz también advierte que un parche cierra una vulnerabilidad pero no puede eliminar a un atacante que entró antes de la corrección. Los equipos aún necesitan revisar registros, procesos, tokens de acceso y nuevas conexiones.
"Una vez que un servidor fue expuesto, no asumas que el parche significa que terminaste", dijo. "Busca señales de que alguien entró, comprueba a dónde fue y aísla la carga de trabajo si encuentras una amenaza."
El objetivo, dice, es contener un incumplimiento sin cortar todos los servicios que la compañía necesita.
Contiene lo que no puedas parchear a tiempo
PHP2Shell pone en marcha dos relojes. Una registra cuánto tiempo necesitan los equipos para probar y desplegar un parche. El otro controla la rapidez con la que un atacante puede encontrar una forma de entrar.
Swartz comparó PHP2Shell con una llave universal de las puertas delanteras. Los equipos no siempre pueden cambiar las cerraduras antes de que alguien pruebe la llave. Pero si conocen los caminos entre cargas de trabajo, limitan el acceso y actúan rápido ante el tráfico inusual, no tiene por qué abrir toda la casa con una sola puerta.
No dejes que una vulnerabilidad se convierta en un incumplimiento a nivel de red
Los atacantes solo necesitan un punto de entrada para comprometer tu entorno.
Illumio te ayuda a detectar movimientos laterales sospechosos, contener amenazas y evitar que los atacantes conviertan una sola vulnerabilidad en un incumplimiento generalizado.
.webp)
