PHP2Shell: Cloudflare frenó el fallo de PHP en 1 de 4 webs

PHP2Shell: el fallo que obligó a desconectar medio internet

El miércoles 21 de octubre, dos vulnerabilidades críticas en PHP registradas como CVE-2026-109618 y CVE-2026-109619 —conocidas ya en todo el mundo como PHP2Shell— obligaron a apagar o aislar servicios en varios continentes. La puntuación de gravedad es de 9,2 sobre 10, y el fallo permite a un atacante sin credenciales ejecutar código malicioso directamente en el servidor.

El alcance del apagón preventivo da la medida del pánico. Webs de gobiernos europeos quedaron sin conexión, el Gobierno de Japón recomendó suspender parte de sus contenidos y muchas empresas optaron por desconectar sus páginas antes que arriesgarse a ser las primeras en caer. Según Cybernews, entre los servicios afectados por apagados preventivos estuvieron Wikipedia (que desactivó algunos sistemas a la espera de actualizaciones), Internet Archive y webs públicas de Países Bajos y Finlandia. El proveedor de wikis Weird Gloop mantuvo sus servidores web apagados durante 13 horas.

Para un founder, esto no es una anécdota de infraestructura ajena. Si tu producto corre sobre WordPress, Laravel, Drupal o Magento, el problema no está en tu aplicación: está en el motor que la ejecuta. Y eso significa que no lo arreglas con una actualización de tu CMS.

Por qué el escudo de Cloudflare importó tanto

Cloudflare había estado desarrollando sus reglas junto a la Fundación PHP, OpenAI y Wiz desde principios de octubre, según detalla la compañía. Ante la previsible avalancha de ataques, activó la protección por defecto el 21 de octubre, casi once horas antes de que se anunciara el parche que solucionaba el problema.

Lo relevante para las startups es a quién cubrió esa barrera. No se limitó a los clientes corporativos: alcanzó también a los clientes con cortafuegos web y a los que usan el plan gratuito. Según datos de W3Techs, ese escudo podría haber sido la única protección para una de cada cuatro webs de todo internet.

Las reglas de seguridad habituales no bastaban, así que la compañía creó la "detección de transacción completa", que analiza la petición del usuario y la respuesta del servidor. Si algo no cuadra, bloquea la respuesta antes de que llegue a quien la pidió. Es la lógica de siempre de un CDN —ponerse entre el visitante y el servidor— llevada a un caso extremo.

Los ataques llegaron antes que el parche

La cronología es la parte más incómoda del caso. Amazon detectó un intento de ataque contra esta vulnerabilidad el 17 de octubre, cuatro días antes de la divulgación, contra uno de sus señuelos (servidores trampa para estudiar atacantes). Llegó desde una red de anonimato comercial y la compañía no sabe cómo obtuvo el atacante esa información.

Después vino la filtración. El martes 20 de octubre los dos identificadores ya circulaban por foros y redes. Una de las firmas que reportó el fallo publicó por error un vídeo con su prueba de concepto y otra soltó imágenes del arreglo más de seis horas antes de lo pactado. El resultado: el anuncio se adelantó y los administradores de todo el mundo se enteraron al mismo tiempo que los atacantes.

La velocidad posterior fue de máquina. Cloudflare detectó miles de intentos de explotación en las diez horas previas al anuncio, según recogía Reuters. Su consejero delegado, Matthew Prince, describió la escalada: "subió a decenas de miles en los 45 minutos posteriores al anuncio. Después, a cientos de miles en dos horas, y ahora a millones".

La IA acortó el camino entre el fallo y el exploit

CJ Moses, jefe de seguridad de Amazon, considera que la IA explica buena parte de ese incremento y que el tiempo entre parche y exploit funcional "se está reduciendo por razones estructurales". El análisis asistido por IA, añadió, lo abarata.

El caso lo confirma. Según El Mundo, tres equipos dieron con los fallos entre finales de julio y agosto, con pocas semanas de diferencia, tras más de una década escondidos en el código de PHP. La firma Calif y el equipo de seguridad de OpenAI usaron el modelo GPT-5.6 Sol, y Wiz (propiedad de Google) combinó ese modelo con Gemini 4 Argon y una herramienta propia. Wiz sostuvo que la IA permitió que un solo investigador hiciera en una semana lo que antes habría llevado meses a un equipo especializado.

Cybernews matiza un punto que circuló mal: el fallo lo encontró un humano, el investigador LCFR de Calif, que desarrolló un exploit funcional en agosto. La IA aceleró el proceso, no lo originó. La distinción importa porque define el riesgo real: la barrera técnica para convertir un fallo antiguo en un ataque funcional se está derrumbando, pero todavía hace falta criterio humano para encontrarlo.

El problema de fondo: software crítico con equipo pequeño

La Fundación PHP admite que el problema se intuyó en 2024, tras una auditoría externa, pero el arreglo se atascó durante meses y ha asumido el "mea culpa" reconociendo que "el retraso fue un fallo estructural".

Según MuyComputer, la complejidad de las correcciones, el temor a provocar incompatibilidades en un ecosistema enorme y la falta de especialistas con conocimiento profundo del motor explican la demora. Es el mismo patrón que dejaron Heartbleed en OpenSSL (2014) y Log4Shell en Log4j: un componente compartido por millones de sitios, mantenido por un equipo reducido y financiado en buena parte por donaciones. La Fundación ya reclama mayor implicación económica de las empresas que dependen de PHP.

El volumen expuesto lo ilustra. Unit 42, la división de investigación de Palo Alto Networks, calcula que más de 22,6 millones de aplicaciones web y servidores están expuestos, según El Mundo. BleepingComputer cita estimaciones de VirusTotal: más de 5,1 millones de hosts PHP accesibles en línea, de los cuales unos 3,8 millones tienen al menos un puerto abierto.

¿Qué significa esto para tu startup?

Si tu equipo técnico son dos personas y un hosting compartido, este episodio te deja tareas concretas para esta semana:

• Verifica tu versión de PHP y actualiza. Los parches son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según BleepingComputer. Actualizar WordPress, Drupal o tu tema no basta: el fallo está en el motor.
• Si estás en PHP 8.1 o anterior, no hay parche oficial. El proyecto publicó backports mínimos para 7.4, 8.0 y 8.1, y algunas distribuciones y proveedores de soporte extendido ofrecen sus propias correcciones. Contacta a tu proveedor o aísla el servicio de internet mientras tanto.
• Mira el calendario, no solo el parche. PHP 8.2 llega a fin de soporte el 31 de diciembre de 2026, según how2shout. Si tu producto sigue en esa rama, la migración no es opcional: es el próximo trimestre.
• Revisa registros desde el 17 de octubre. Amazon recomendó investigar actividad sospechosa desde esa fecha en lugar de asumir que los ataques empezaron con la divulgación pública.
• No confundas mitigación con solución. El propio equipo de seguridad de PHP advirtió que ninguna configuración temporal bloquea todos los ataques: solo el parche oficial es defensa permanente. Un WAF o un CDN con reglas actualizadas compra tiempo, no cierra el agujero.

Hay una lección de producto además de una técnica. La mayoría de las startups hispanohablantes no tiene un CISO, y eso no va a cambiar. Lo que sí puede cambiar es tratar la dependencia de infraestructura como una decisión de negocio: saber qué versión de qué lenguaje sostiene tu facturación, quién la actualiza y cuánto tardarías en migrar si mañana aparece un CVE de 9,2.

Conclusión

PHP2Shell no fue solo un fallo grave: fue una demostración de que el tiempo entre la divulgación de una vulnerabilidad y su explotación masiva se mide en horas, no en semanas. La filtración rompió el calendario coordinado, la IA abarató el desarrollo del exploit y millones de sitios quedaron dependiendo de que un tercero —Cloudflare— hubiera hecho los deberes once horas antes.

Para un founder, la conclusión práctica es incómoda pero simple: la seguridad de tu producto no depende solo de tu código, sino de la salud de los proyectos open source que lo sostienen y de tu velocidad para reaccionar cuando alguien más falla. Tener inventariada tu infraestructura y un plan de parcheo con nombre y apellido vale más que cualquier herramienta comprada a las apuradas.

Fuentes

• Xataka: PHP ha sido la brecha, Cloudflare ha sido el escudo (fuente original)
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
• Cybernews: Amazon and Cloudflare report PHP2Shell cyberattack attempts
• El Mundo: Así es PHP2Shell, el fallo que amenaza a siete de cada diez webs
• MuyComputer: PHP2Shell, el fallo de PHP que ha puesto en jaque a Internet
• How2Shout: PHP2Shell, critical PHP flaws allow unauthenticated RCE