Seguridad de servidores en la era de la IA (parte 1): de la mantención periódica a la continua

Primera parte de una serie sobre seguridad de servidores. La inteligencia artificial no solo ayuda a escribir código: también ayuda a encontrar sus fallas y a aprovecharlas. Eso cambia el ritmo de la seguridad. Revisar los servidores una vez al mes ya no alcanza; hoy la mantención tiene que ser continua. Y como ningún sistema es infalible, también hay que estar preparado para recuperarse cuando algo falla. Lo contamos a partir de un caso real: cómo respondimos en ITLab a dos vulnerabilidades críticas de PHP.

Qué cambió

Una vulnerabilidad es un error en un programa que permite a alguien hacer lo que no debería: entrar sin permiso, leer datos ajenos o tomar el control de un equipo. Siempre han existido. Lo nuevo es la velocidad.

Con herramientas de IA, revisar millones de líneas de código en busca de errores es más rápido y más barato que nunca. Eso lo aprovechan quienes defienden, que encuentran y corrigen fallas antes, pero también quienes atacan. El resultado es que se publican vulnerabilidades a un ritmo mucho mayor que hace pocos años, y que el tiempo entre el aviso público de una falla y los primeros intentos de explotarla se ha acortado: a veces pasan días; a veces, horas.

Las advertencias vienen también desde dentro de la industria de la IA. Anthropic presentó en abril de 2026 su modelo Mythos Preview y, según Epoch AI, afirmó que al 22 de mayo ya se había usado para identificar más de diez mil errores de severidad alta o crítica, no todos publicados. Y Dario Amodei, director ejecutivo de Anthropic, plantea en su ensayo «We Must Pace the Frontier» un escenario de riesgo: le preocupa que, en 6 a 12 meses, un enjambre de agentes de IA pudiera tomar el control de gran parte de internet con una red persistente de equipos comprometidos, con daños de cientos de miles de millones de dólares. No es un hecho ni una predicción cerrada, sino un riesgo que el autor considera plausible.

Jason Clinton, subdirector de seguridad de la información de Anthropic, fue en la misma línea. Según la crónica de Brodersen Dark News sobre un panel en la conferencia DEF CON de 2026, dijo que vienen «entre 18 y 24 meses» que podrían ser los más intensos en las carreras de quienes trabajan en ciberseguridad. Y en octubre escribió en X, según WION y otros medios, que los ataques «van a empeorar mucho antes de mejorar» y que hay que resistir unos 18 meses. Es su pronóstico, no un plazo confirmado.

La propia Anthropic reconoció un caso de este tipo. Según Infobae, en el documento que presentó ante la SEC para su salida a bolsa, la empresa informó que cuatro de sus modelos accedieron sin autorización a sistemas reales de terceros durante un ejercicio de ciberseguridad mal configurado por un socio externo, y que no encontró pruebas de coordinación entre los modelos ni de intentos de eludir la supervisión.

Los números

Las cifras públicas muestran el salto. Según la herramienta «CVE statistics», de Daniel Christensen, que consulta a diario la base nacional de vulnerabilidades de Estados Unidos (NVD, del NIST), al 30 de octubre de 2026:

Con otra base, la del programa CVE, el análisis de Guru Chahal, con datos al 25 de octubre de 2026, muestra lo mismo mes a mes:

Es más del triple de publicaciones al mes, y casi cinco veces más de severidad crítica. Brandefense llega a un promedio similar con el NVD para julio a septiembre de 2026 (12 320 al mes, según sus datos al 26 de octubre). Una cautela que las propias fuentes hacen: el aumento coincide con la búsqueda de errores con IA, pero sus datos no permiten afirmar que sea la causa.

Por qué la mantención periódica ya no alcanza

Durante años, el modelo habitual fue revisar y actualizar los servidores cada cierto tiempo: una ventana de mantención mensual o trimestral. Si una corrección sale un lunes y la próxima ventana es en tres semanas, el sistema queda expuesto todo ese tiempo, justo cuando más gente sabe cómo atacarlo.

Por eso la mantención pasa de periódica a continua. Hoy es normal que en un mismo día aparezcan varias actualizaciones de seguridad relevantes, y cada una exige decidir rápido si aplica, cuándo instalarla y cómo comprobar que funcionó.

Un caso real: dos vulnerabilidades críticas de PHP

En octubre, PHP, el lenguaje con que funcionan muchísimos sitios y aplicaciones web, publicó correcciones para dos vulnerabilidades críticas, conocidas como PHP2Shell, que permitían ejecutar código de forma remota sin autenticación: en la práctica, que alguien desde internet tomara el control de una aplicación sin necesidad de contraseña.

El caso ilustra bien el nuevo ritmo. Según The Register y TechTarget, las fallas se encontraron con ayuda de IA: la firma Calif halló una usando un modelo de OpenAI, y Wiz las encontró de forma independiente con herramientas que incluían modelos de IA; TechTarget cita a Wiz diciendo que un solo investigador hizo en una semana lo que antes habría tomado meses a un equipo de primer nivel. Amazon registró un intento de explotación en sus sistemas trampa cuatro días antes del anuncio público. Tras la publicación, el CEO de Cloudflare informó en X que los intentos de ataque bloqueados pasaban de miles a millones, e Imperva contó, según TechTarget, más de 480 000 solicitudes de ataque contra unos 22 000 sitios en 103 países en 24 horas.

Varios gobiernos sacaron sitios de línea como precaución mientras aplicaban las correcciones. Según The Register, la ministra británica de tecnología informó en la Cámara de los Lores que 32 servicios del gobierno no estaban disponibles y cuatro lo estaban en parte, sin compromiso confirmado de los sistemas centrales. Finlandia también desconectó sitios públicos de forma preventiva, y medios como The Register y TechTarget reportaron medidas similares en Países Bajos, Francia, Alemania, Bélgica y Chequia.

Y hubo intrusiones confirmadas. Según la firma Dream, cuyos hallazgos verificó de forma independiente la unidad Unit 42 de Palo Alto Networks según The Register, atacantes que Dream sospecha de origen chino, sin atribución confirmada, construyeron su propio exploit de PHP2Shell, lo combinaron con una segunda falla y obtuvieron control total de 25 equipos en Estados Unidos, Japón, Taiwán y Corea del Sur. Eran sobre todo cortafuegos con su interfaz de administración expuesta a internet, incluidos sistemas de un entorno afiliado al gobierno estadounidense. Dream encontró herramientas de IA en la infraestructura de los atacantes, aunque sin evidencia directa de que la IA escribiera el exploit. La agencia de ciberseguridad de Estados Unidos (CISA) agregó las fallas de PHP2Shell a su catálogo de vulnerabilidades explotadas activamente. La lección es doble: lo que se publica se explota, y una interfaz de administración nunca debería estar abierta a internet.

Así respondimos en nuestros servidores:

1. Saber qué corría de verdad. Primero identificamos qué versión de PHP ejecutaba realmente cada aplicación. No basta con mirar el paquete instalado en el servidor ni con descargar una imagen etiquetada como «la última»: una aplicación puede estar usando otra versión distinta.
2. Respaldar antes de tocar. Respaldamos configuraciones, bases de datos y archivos.
3. Mitigar mientras no había corrección. Mientras no estaban publicados los programas corregidos, aplicamos una mitigación temporal.
4. Actualizar el mismo día. Apenas se publicaron las versiones corregidas, las instalamos ese mismo día.
5. Verificar en ejecución. Comprobamos en los procesos y contenedores en funcionamiento que corrían las versiones nuevas, no solo que estuvieran instaladas.

Después dejamos instaladas revisiones automáticas periódicas que buscan la versión corregida, respaldan antes de actualizar, validan que todo siga funcionando y revierten el cambio si la validación falla.

En los días siguientes actualizamos también el gestor de contenido, el sistema operativo, el motor de contenedores y las herramientas de despliegue, a medida que hubo versiones verificables. Ahí apareció un caso que vale la pena contar: una pieza del sistema todavía apuntaba a la versión antigua, aunque el sistema ya ejecutaba la nueva. Lo detectamos al verificar y lo corregimos. Es el mejor ejemplo de por qué no basta con instalar: hay que comprobar lo que realmente corre.

Qué significa mantener un sistema de forma continua

Mantener un servidor protegido ya no es solo «instalar actualizaciones». Son cuatro tareas que se repiten todo el tiempo:

1. Vigilar. Saber, apenas se publica una vulnerabilidad, si afecta a algo que uno tiene en funcionamiento. Requiere un inventario al día de qué software corre y dónde.
2. Parchear. Aplicar la corrección pronto, priorizando lo que está expuesto a internet y lo que maneja datos sensibles. Hay que distinguir dos casos. Ante una vulnerabilidad de peligro inminente, con recomendación de parchar de inmediato, la corrección se aplica en minutos o pocas horas. Las actualizaciones corrientes, en cambio, conviene instalarlas después de unas horas, cuando la comunidad ya confirmó que son sanas: a veces una actualización resulta falsa o viene infectada, y ser el primero en instalarla también es un riesgo.
3. Verificar lo que realmente corre. Que el paquete corregido esté instalado no significa que el servicio lo esté usando: muchos programas siguen ejecutando la versión antigua hasta que se reinician. La verificación tiene que mirar lo que está en funcionamiento, no solo lo que está en el disco.
4. Poder revertir. Toda actualización puede romper algo. Tener respaldos y un camino probado para volver atrás permite parchear rápido sin miedo a dejar el servicio caído.

Por qué automatizar la vigilancia con agentes

Hacer estas cuatro tareas a mano, varias veces al día y en muchos equipos, no escala. Aquí la IA también sirve para defender: agentes de software que revisan de forma constante los avisos de seguridad, los cruzan con lo que cada sistema tiene en funcionamiento y preparan o apoyan el parcheo apenas sale una corrección.

En ITLab ya trabajamos así: tenemos un contingente de agentes dedicados a monitorear vulnerabilidades y a apoyar la aplicación de parches en cuanto se publican las correcciones. Cuando una vulnerabilidad es de peligro inminente, aplicamos la corrección en minutos o pocas horas; nunca esperamos un día.

Los agentes no trabajan solos. Cada uno opera con un contexto limitado, y ninguno tiene la visión global del sistema. Esa visión es la parte humana: una persona encarga las tareas a los agentes, revisa lo que hacen, sigue las noticias de seguridad y conoce cómo está construido todo el sistema. La automatización acorta el tiempo entre el aviso y la acción, que es justamente lo que la IA está acortando del lado de quienes atacan; el criterio humano decide qué hacer y responde cuando algo falla.

Ningún proceso garantiza seguridad absoluta. Lo que sí se puede controlar es la velocidad y la disciplina de la respuesta.

Nada es infalible: la otra mitad es poder recuperarse

Vigilar y parchear reduce el riesgo, pero no lo elimina. Hoy cualquier sistema puede sufrir un ataque, un error humano o una falla que termine en pérdida de información. Por eso la seguridad necesita dos cosas a la vez: recursos dedicados a vigilar y parchear sin pausa, y una estrategia sólida para que, si algo ocurre, los datos sigan disponibles e intactos.

Una estrategia de respaldo y custodia de datos que esté a la altura incluye:

• Copias separadas del sistema principal. Un respaldo guardado en el mismo servidor, o al que se llega con las mismas credenciales, cae junto con él.
• Historial de versiones. Poder volver a como estaban los datos ayer, la semana pasada o el mes pasado, no solo a la última copia, que podría estar ya dañada.
• Respaldos inmutables. Copias que nadie puede modificar ni borrar durante un período definido, ni siquiera quien tome el control del servidor. Es la defensa directa contra los ataques que cifran o eliminan también los respaldos.
• Cifrado. Que una copia robada no sirva a quien la robó.
• Restauraciones probadas. Un respaldo que nunca se ha restaurado es una promesa, no una garantía. Hay que probar con regularidad que los datos vuelven completos y medir cuánto tarda en volver a funcionar el servicio.

En ITLab aplicamos esta lógica: nuestra información está copiada más de una vez, en distintos equipos y discos locales, y además en la nube.

Qué preguntarle a su proveedor de TI

Si su empresa tiene servidores propios, en la nube o administrados por terceros, estas preguntas ayudan a saber si la mantención está a la altura del ritmo actual:

• ¿Cuánto tardan en aplicar una corrección de seguridad desde que se publica? Las urgentes deberían aplicarse en minutos u horas; el resto, después de una breve verificación de que la actualización es sana.
• ¿Tienen un inventario actualizado de lo que corre en nuestros sistemas? Sin inventario no se puede saber qué afecta cada aviso.
• ¿Cómo verifican que la corrección quedó activa, y no solo instalada?
• ¿Qué pasa si una actualización rompe algo? ¿Hay respaldos probados y un procedimiento para volver atrás?
• ¿Vigilan los avisos de seguridad de forma continua o solo en ventanas de mantención?
• ¿Nos informan qué se actualizó y cuándo?
• ¿Dónde están nuestros respaldos y están separados del sistema principal?
• ¿Los respaldos son inmutables? Es decir, ¿podría borrarlos o cifrarlos alguien que tomara el control del servidor?
• ¿Cuándo fue la última prueba de restauración y qué resultado dio?
• Si perdemos el servidor, ¿cuánto tardaríamos en volver a operar y cuántos datos podríamos perder?

Qué puede hacer su empresa para prevenir y recuperarse

• Mantener actualizados también los equipos y programas de uso diario: computadores, teléfonos, navegadores y el sitio web.
• Reducir lo expuesto a internet a lo que realmente necesita estarlo.
• Exigir respaldos separados, inmutables y cifrados, y pedir que se pruebe su restauración con regularidad.
• Usar autenticación de dos factores en correo, sistemas administrativos y accesos remotos.
• Definir quién responde si ocurre un incidente, antes de que ocurra.

Preguntas frecuentes

¿La IA hace más inseguros los sistemas? No los hace más débiles, pero acelera el hallazgo de sus fallas, tanto para quienes defienden como para quienes atacan. Eso obliga a responder más rápido.

¿Cada cuánto hay que actualizar un servidor? Ya no hay una frecuencia fija: hay que aplicar las correcciones de seguridad relevantes en cuanto salen, con prioridad para lo expuesto a internet.

¿Basta con instalar las actualizaciones? No. Hay que comprobar que los servicios estén usando la versión corregida y tener cómo revertir si algo falla.

Si vigilo y parcheo, ¿necesito además respaldos? Sí. Ningún sistema es infalible, y los respaldos separados, inmutables y probados son lo que permite recuperarse si un ataque o un error llega a ocurrir.

¿Qué es un respaldo inmutable? Una copia que no se puede modificar ni borrar durante un período definido, ni siquiera con acceso total al servidor. Protege contra ataques que intentan destruir también las copias.

¿Hay que instalar todas las actualizaciones apenas salen? Las de seguridad urgentes, sí. Las corrientes conviene instalarlas tras unas horas, cuando la comunidad ya confirmó que son sanas, porque a veces una actualización resulta falsa o viene infectada.

¿Qué hace ITLab al respecto? Mantiene agentes que monitorean vulnerabilidades de forma continua y apoyan el parcheo apenas se publican las correcciones. Una persona dirige y revisa ese trabajo: los agentes operan con contexto limitado, y la visión global del sistema es humana. Además, nuestra información está respaldada más de una vez, en equipos locales y en la nube.

Fuentes

• Brandefense, «CVE Statistics 2026: Why Vulnerability Volume Is Surging» (octubre de 2026), con datos del NVD del NIST.
• Guru Chahal, «CVEs by the numbers» (octubre de 2026), con datos del programa CVE.
• Dario Amodei, «We Must Pace the Frontier» (septiembre de 2026).
• Epoch AI, «Data on cyber vulnerabilities» (actualizado el 30 de octubre de 2026), licencia CC BY 4.0.
• Daniel Christensen, «CVE statistics» (datos del NVD al 30 de octubre de 2026), licencia CC BY 4.0.
• Brodersen Dark News, «Vienen entre 18 y 24 meses que podrían ser los más intensos de nuestras carreras» (agosto de 2026).
• WION, sobre la advertencia de Jason Clinton (octubre de 2026).
• Infobae, sobre el documento de Anthropic ante la SEC (octubre de 2026).
• The Register, sobre PHP2Shell y los servicios del gobierno británico (octubre de 2026).
• TechTarget, cronología de PHP2Shell (octubre de 2026).
• Dream, «Chained PHP2Shell Exploit Roots 25 Servers» (octubre de 2026).
• The Register, sobre la campaña que comprometió 25 servidores (octubre de 2026).

Sigue la serie

• Ciberseguridad en Chile: PHP2Shell, ransomware y las leyes que vienen
• Lo que no se arregla con un parche: vulnerabilidades de hardware

Contacto

Si quiere revisar cómo se mantienen los servidores de su organización o llevar su mantención a un modelo continuo, ITLab puede ayudarle. Contáctenos.

Actualizado el 30 de octubre de 2026.