El 21 de octubre, una vulnerabilidad informática obligó a instituciones brasileñas a tomar una decisión incómoda: restringir el acceso a sus sistemas antes de que alguien pudiera aprovechar sus debilidades. La Universidad Federal de Maranhão y el Tribunal Regional Federal de la Primera Región suspendieron preventivamente el acceso externo a sus plataformas de gestión documental. No anunciaron haber sido víctimas de un ataque. Actuaron ante el riesgo de sufrirlo.
La alerta cruzó fronteras. El FBI, las autoridades británicas de ciberseguridad y otros organismos internacionales advirtieron sobre dos vulnerabilidades críticas conocidas como PHP2Shell, capaces, bajo determinadas condiciones, de permitir la ejecución remota de código sin autenticación. La recomendación llegó al extremo de considerar la desconexión temporal de sistemas que no pudieran protegerse a tiempo.
PHP está detrás de una parte importante de internet. Desde portales gubernamentales hasta aplicaciones empresariales, numerosas plataformas dependen de este lenguaje. WordPress, Joomla y Drupal, tres conocidos gestores de contenido o CMS, también lo utilizan. Eso no los convierte en inseguros. De hecho, organismos estadounidenses utilizan Drupal. El riesgo aparece cuando desconocemos qué versiones están funcionando, qué componentes dependen de ellas y quién tiene la responsabilidad de mantenerlas.
La Fundación PHP reconoció que uno de los problemas tenía antecedentes desde 2024 y que las dificultades técnicas y de recursos retrasaron su corrección. Los parches públicos llegaron el 21 de octubre. Conviene aclararlo: las medidas adoptadas en Brasil no demuestran negligencia ni dependencia de un proveedor externo. Tampoco prueban que esas instituciones hubieran ignorado actualizaciones disponibles.
Pero este episodio internacional me lleva a una preocupación que conozco de cerca.
En Venezuela y Latinoamérica he visto casos en los que la confianza depositada en un proveedor tecnológico termina convirtiéndose en una dependencia difícil de justificar.
Instituciones que tienen programadores, administradores de bases de datos y departamentos completos de tecnología, pero que heredaron sistemas cuyo funcionamiento sigue dependiendo de una sola persona externa. Ese proveedor conserva accesos privilegiados, conoce configuraciones que nadie documentó y ejecuta tareas que el personal interno debería poder supervisar.
A veces comienza como un servicio adicional. El proveedor resuelve una emergencia, modifica una configuración o hace un mantenimiento que ni siquiera estaba contemplado en su contrato. La institución agradece la ayuda. Después vuelve a llamarlo. Con los años, aquel apoyo excepcional puede convertirse en una dependencia permanente.
Y aquí surge una pregunta incómoda: ¿estamos contratando conocimiento especializado o estamos pagando para seguir dependiendo de alguien?
En continuidad de negocio, esto puede representar un Single Point of Failure, un punto único de falla. Si una sola persona concentra los conocimientos, accesos y procedimientos indispensables para recuperar un servicio, su ausencia puede comprometer toda la operación.
No cuestiono el outsourcing. Cuestiono la delegación de confianza sin controles, sin transferencia de conocimiento y sin mecanismos efectivos de supervisión.
Hay otra dimensión que merece especial atención: la responsabilidad de la asesoría legal.
Los departamentos jurídicos deben revisar con ojo crítico los contratos tecnológicos, especialmente los heredados. No basta con comprobar cuánto cobra el proveedor o cuándo vence su contrato. Hay que determinar qué actividades tiene autorizadas, cuáles son sus obligaciones de mantenimiento, quién debe comunicar las vulnerabilidades y hasta dónde llegan sus privilegios administrativos.
Porque una cosa es prestar un buen servicio y otra intervenir sistemas fuera de las autorizaciones concedidas.
En Venezuela, la Ley Especial contra los Delitos Informáticos contempla delitos relacionados con el acceso indebido y el sabotaje o daño informático, incluidos determinados supuestos de imprudencia, negligencia, impericia o inobservancia de normas. Dependiendo de los hechos y de los requisitos legales acreditados, estas conductas pueden acarrear responsabilidad penal y penas de prisión.
La buena fe no sustituye una autorización. Y la ignorancia de la ley tampoco constituye una excusa.
El patch management es mucho más complejo de lo que parece.
La gestión de parches no consiste simplemente en descargar una actualización y reiniciar un servidor. Hay que identificar versiones vulnerables, evaluar dependencias, comprobar compatibilidad con aplicaciones antiguas, respaldar configuraciones, realizar pruebas y preparar procedimientos de recuperación.
En una plataforma gubernamental, actualizar PHP puede afectar sistemas desarrollados hace años, bibliotecas que dejaron de recibir soporte o aplicaciones conectadas a bases de datos críticas. Una actualización mal ejecutada puede interrumpir servicios esenciales. No actualizar, por su parte, puede mantener abierta una vulnerabilidad grave.
Por eso la gestión de parches necesita inventarios confiables, responsables definidos, ventanas de mantenimiento, pruebas automatizadas y planes de reversión. También debe contemplar medidas temporales cuando la actualización inmediata no sea viable.
Y aquí aparece una oportunidad que todavía estamos desaprovechando: la inteligencia artificial.
¿Por qué seguir dependiendo de revisiones manuales para descubrir versiones vulnerables? ¿Por qué esperar a que alguien recuerde comprobar un servidor?
Hoy podemos automatizar inventarios, correlacionar vulnerabilidades con activos, identificar configuraciones riesgosas y utilizar IA para apoyar el análisis de incidentes y la generación de pruebas. La aprobación de cambios críticos debe seguir bajo supervisión humana, pero muchas tareas repetitivas pueden ejecutarse continuamente.
Esto también tiene una relación directa con los ataques de día cero, aquellos que explotan vulnerabilidades desconocidas o para las cuales todavía no existe una corrección disponible.
Cuando no hay parche, la vigilancia del comportamiento puede marcar la diferencia.
La heurística permite identificar actividades sospechosas mediante patrones e indicios, incluso cuando todavía no existe una firma conocida del ataque. Un servidor que comienza a ejecutar procesos inusuales, un cambio inesperado de privilegios o una modificación no autorizada pueden activar alertas antes de que el incidente se extienda.
La revisión continua de los logs, combinada con análisis heurístico, detección de anomalías y controles automáticos de contención, puede prevenir algunas intrusiones, bloquear intentos de explotación o limitar sus consecuencias. No garantiza detener todos los ataques de día cero, pero permite responder sin esperar necesariamente a conocer el código malicioso.
La IA puede fortalecer esa capacidad al correlacionar grandes volúmenes de eventos y ayudar a distinguir comportamientos legítimos de posibles amenazas. Naturalmente, requiere datos confiables, reglas de respuesta y supervisión para evitar bloqueos injustificados.
Por eso considero indispensable realizar auditorías independientes sobre los terceros con accesos críticos. No solamente auditorías de vulnerabilidades, también de contratos, privilegios, obligaciones, documentación y continuidad operativa.
Una prueba sencilla puede revelar mucho: ¿podría el equipo interno actualizar y recuperar una plataforma crítica si mañana su proveedor habitual dejara de estar disponible?
Si la respuesta es negativa, hay una dependencia que debe corregirse.
Y del otro lado del mundo, Japón ofrece otra advertencia. El 7 de octubre, un ataque de ransomware contra el proveedor de nube IDC Frontier afectó a cientos de empresas y gobiernos locales. Días después, Masaaki Taira, responsable de estrategia de ciberseguridad del partido gobernante, describió la situación como una emergencia en el ciberespacio. No se ha establecido que esos incidentes estén relacionados con PHP2Shell, pero muestran otra cara del mismo riesgo: cuando un proveedor tecnológico falla, las consecuencias pueden extenderse simultáneamente a numerosas organizaciones.
La lección para Venezuela y Latinoamérica es concreta. Debemos revisar qué control conservamos sobre nuestros sistemas, qué hemos delegado, qué obligaciones están documentadas y cuánto tardaríamos en recuperar una operación crítica.
Porque cuando aparece una vulnerabilidad que amenaza a buena parte de internet, el peor momento para descubrir quién tiene las llaves de nuestros servidores es cuando necesitamos utilizarlas.
Rafael Núñez Aponte
CEO de @MasQueSeguridad
Columnista Radar Cibernético