PHP2Shell: el aviso más reciente
El 21 de octubre de 2026, PHP publicó parches de emergencia para dos fallas críticas en el núcleo del lenguaje, denominadas PHP2Shell (CVSS 9.2), que permiten a un atacante sin credenciales ejecutar código en el servidor. Los ataques comenzaron antes del parche: PHP solo corrigió las ramas 8.2 a 8.5, y cerca de 884,000 servidores expuestos a internet, el 59% de los que declaraban su versión, usaban versiones sin soporte. Para ellos no hubo un "actualiza y listo".
React2Shell (JavaScript, 2025), ToolShell en SharePoint (.NET, 2025) y Apache Struts (Java, 2017) siguieron el mismo guion: un componente que todos usan, acceso remoto sin contraseña y atacantes que llegan en horas.
El CORE legado: viejo, opaco y difícil de defender
La obsolescencia convierte un parche de un día en un proyecto de meses. Muchas aseguradoras operan con plataformas CORE de 20 o 30 años poco documentadas, rodeadas de portales, APIs y robots que multiplican la superficie de ataque.
Cambiar el CORE no es la solución para todo. Un reemplazo toma de uno a tres años o más, puede superar los 11 millones de dólares y muchos de estos proyectos fracasan o terminan con sobrecostos. Mientras tanto, el sistema viejo sigue en producción y expuesto. Y el CORE nuevo también envejecerá: sin disciplina de actualización, será el legado de 2035.
El sector asegurador ya está en la lista
En 2024, a Qualitas le robaron 5.5 terabytes. Genworth y Prudential perdieron datos de millones de clientes debido a una falla en MOVEit de un proveedor. Change Healthcare, de UnitedHealth, entró en crisis por un portal heredado sin autenticación multifactor: 22 millones de dólares en rescate y costos de 2,870 millones de dólares.
Y hay un riesgo que no aparece en los titulares: el fraude en los siniestros. Quien controla un CORE vulnerable puede alterar montos, reservas o cuentas de beneficiarios; con datos robados, fabricar reclamaciones o suplantar agentes. La higiene tecnológica también es un control antifraude.
“Run The Business” vs. “Change The Business”
Actualizar un “runtime” no cabe ni en "run" ni en "change": el indicador de "run" premia no tocar nada, el presupuesto de "change" premia lo nuevo y la obsolescencia no tiene dueño de negocio. Ese espacio entre ambas prioridades es por donde entran los atacantes.
Más allá de SAST y DAST
SAST y DAST no te habrían avisado de PHP2Shell: la falla estaba en el intérprete, no en tu código. Hace falta un inventario en vivo de activos y “runtimes”, un SBOM, una política de fin de soporte con presupuesto asignado, priorización basada en la explotación real, controles compensatorios, proveedores bajo el mismo estándar y métricas de higiene para el consejo.
Un excelente caso de uso de IA con un óptimo ROI
Sí se puede: un banco mexicano de categoría Tier 1 eliminó más de 18,000 vulnerabilidades en 90 días con una solución de IA desarrollada por GFT. Sin ella, el mismo trabajo habría tardado más de 10 meses en un equipo grande y dedicado. La clave fue el modelo “Human in the Loop”: la IA asume el trabajo repetitivo y masivo, y los especialistas revisan y aprueban cada corrección. Es viable técnica y financieramente.
Si no actúas ahora, el problema eres tú. Ya no puedes decir que no sabías: las alertas son públicas, los casos están documentados y las herramientas existen. Ya no puedes decir que no hay presupuesto ni equipo: la IA con especialistas convierte diez meses de trabajo en noventa días. Lo único que queda entre tu organización y el próximo PHP2Shell es una decisión, y esa decisión es tuya. El próximo ataque no va a esperar a tu próximo comité de priorización. Empieza hoy, para no tener que dar explicaciones mañana.
%20(1).webp "Ciberseguridad: La “final invisible” del Mundial 2026")
