El miércoles 21 de octubre, el equipo de PHP liberó parches de emergencia para dos fallas críticas bautizadas como PHP2Shell. Fue una de las noticias de seguridad más comentadas del día: la recogieron BleepingComputer, Help Net Security, SecurityWeek, Ars Technica y Techmeme, y en pocas horas ya tenía hasta su propia página en Wikipedia. La razón es simple: PHP mueve una parte enorme de la web, y estas fallas permiten tomar el control de un servidor sin necesidad de contraseña.

Imagen ilustrativa del artículo Foto: Stanislav Kondratiev / Pexels

Qué pasó

  • Las vulnerabilidades son la CVE-2026-109618 y la CVE-2026-109619. Ambas permiten ejecutar código de forma remota y sin autenticación, con los permisos del proceso que atiende la web.
  • PHP las califica con 9,2 sobre 10 en la escala CVSS v4.0; la firma watchTowr les asigna un 10.
  • Afectan a cualquier instalación de PHP que sirva páginas web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto está en mod_php, donde una sola petición maliciosa puede activar el ataque antes de que se ejecute el código de la aplicación.
  • Las versiones corregidas son 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para 7.4, 8.0 y 8.1 solo hay parches mínimos en código fuente o paquetes de distribuciones y proveedores con soporte extendido. Las ramas más antiguas, como PHP 5, no tienen arreglo: hay que migrar.
  • Los detalles se filtraron antes de la fecha de publicación coordinada. Amazon dice haber detectado un intento de explotación en sus señuelos (honeypots) el 17 de octubre, cuatro días antes del parche, y Cloudflare también reportó ataques tempranos. No se sabe cómo obtuvo la información el atacante.
  • El propio equipo de PHP advierte que ningún cambio de configuración bloquea el ataque por completo: el parche es la única defensa definitiva. El NCSC del Reino Unido llegó a recomendar desconectar los sistemas que no se puedan actualizar de inmediato.

Hay versiones distintas en dos puntos. El crédito del hallazgo varía según la fuente (algunas citan a Calif, OpenAI y Wiz; otras solo a Wiz). Y sobre la explotación activa, unas firmas la dan por confirmada, mientras que otras la consideran todavía en investigación.

Por qué importa

Si tienes una tienda en línea, un blog, una landing de campaña o el sitio de un cliente, es muy probable que dependa de PHP. Es la base de buena parte de los gestores de contenido más usados, como WordPress, y de muchos sistemas de comercio electrónico. VirusTotal estima más de 5,1 millones de servidores con PHP expuestos en internet.

En Latinoamérica, muchos negocios contratan hosting compartido económico o tienen un sitio que "alguien armó hace años" y que nadie mantiene. Ese es el perfil más expuesto: versiones viejas de PHP, sin responsable técnico y sin monitoreo. Para una agencia o un freelancer que administra decenas de sitios de clientes, el problema se multiplica.

Lo que está en juego no es solo que el sitio se caiga. Un servidor comprometido puede servir para robar datos de clientes, inyectar spam o malware, o redirigir tráfico pagado a páginas fraudulentas. En ese caso pierdes la inversión en anuncios y la confianza de tu marca.

Nuestro análisis

PHP2Shell deja tres lecciones que van más allá de esta falla puntual.

La ventana para parchear ya casi no existe. Antes había días o semanas entre la publicación de una falla y su explotación masiva. Aquí los detalles se filtraron antes del parche y los ataques empezaron antes de que existiera la corrección. Sansec llegó a predecir que la explotación masiva empezaría a los 15 minutos de publicarse el arreglo. Para una pyme, eso significa que "lo actualizo la próxima semana" ya no es una opción realista.

El software heredado es una deuda que se cobra de golpe. Que PHP 5 o 7 sigan corriendo en producción no es raro; lo raro es que alguien lo tenga en el radar. Cuando aparece una falla así, esos sitios quedan sin parche oficial y la única salida es una migración apurada, más cara y riesgosa que una actualización planificada.

La IA también está acelerando la búsqueda de fallas. Que una empresa de IA aparezca, según algunas fuentes, entre los descubridores encaja con una tendencia: las herramientas automáticas ayudan a encontrar errores profundos en software que se usa hace décadas. Es una buena noticia para la defensa, pero también anticipa más avisos críticos y más seguidos. Prepárate para parchear más rápido y más a menudo.

Para la industria del hosting en la región hay una oportunidad: los proveedores que actualicen pronto y lo comuniquen con claridad pueden ganar clientes. Los que callen pueden perderlos. Para las agencias, ofrecer mantenimiento y seguridad como servicio mensual deja de ser un extra y se convierte en un argumento comercial muy concreto.

Qué hacer ahora

  1. Revisa qué versión de PHP usa cada sitio. Lo encuentras en el panel del hosting (cPanel, Plesk u otro) o pidiéndoselo al proveedor. Si no es 8.5.12, 8.4.27, 8.3.36 o 8.2.35 o superior, actualiza hoy.
  2. Escribe a tu proveedor de hosting y pregunta si ya aplicó los parches de PHP2Shell (CVE-2026-109618 y CVE-2026-109619). Pide la respuesta por escrito.
  3. Si usas Cloudflare, aprovecha que ya activó reglas de protección para todos sus clientes, incluidos los gratuitos. Pero no lo tomes como sustituto del parche: es una barrera temporal.
  4. Planifica la migración de los sitios con PHP 8.1 o anterior. Esas ramas ya no tienen soporte oficial, y esta no será la última falla.
  5. Busca señales de intrusión: usuarios administradores nuevos, archivos modificados recientemente o redirecciones extrañas. Ten un respaldo reciente listo antes de tocar nada.

Fuentes