¿Confiamos en el código? Por qué el software en el que más confiamos es el que menos se analiza

Este artículo forma parte de una serie en curso de nuestros propios especialistas, en la que comparten las investigaciones de vanguardia que utilizan para reforzar nuestros servicios de detección y respuesta gestionados (MDR), líderes a nivel mundial, y proteger a los clientes frente a las amenazas en constante evolución de la era de la IA.

Un equipo lanza una corrección de seguridad, cierra el aviso y sigue adelante. Semanas más tarde, los analistas descubren una vulnerabilidad muy relacionada, solo a unas líneas del parche original. Visto desde fuera, estos hallazgos pueden parecer una casualidad, un golpe de suerte o quizá un talento excepcional para detectar vulnerabilidades. En la práctica, suelen ser más bien el resultado de un enfoque muy disciplinado a la hora de revisar el código.

Según mi propia experiencia al notificar CVE en proyectos conocidos, los hallazgos que resisten un escrutinio riguroso provienen de unos cuantos hábitos de revisión aplicados de forma constante a lo largo del tiempo. Esos hábitos son sencillos: paciencia, perseverancia y la voluntad de leer código que otros ya han dado por correcto.

Este artículo explora esos hábitos de revisión, repasa en detalle la divulgación pública de una vulnerabilidad y examina los riesgos de conectar agentes de IA a la infraestructura de producción. Es una guía para todos los especialistas en código —desde autores hasta analistas— para que perfeccionen su capacidad de identificar vulnerabilidades antes que los atacantes y desarrollen software seguro y resistente.

Cuatro hábitos que dan sus frutos

La mayoría de las vulnerabilidades que se tratan en este artículo se descubrieron utilizando el mismo conjunto riguroso de técnicas de revisión de código; ninguna de ellas es novedosa ni compleja. Son simplemente hábitos prácticos que centran tu atención en aquellas áreas del código donde a menudo se acumulan suposiciones y el escrutinio se relaja. Aquí están mis cuatro principales.

Búsqueda de variantes

Trata cada corrección como una pista, no como un caso cerrado. El mismo error suele aparecer más de una vez: un desarrollador que cometió un error en un lugar puede haberlo cometido también en otro, más o menos al mismo tiempo y bajo las mismas suposiciones. Un error o vulnerabilidad conocido suele ser la forma más rápida de encontrar el siguiente.

Análisis de las lagunas entre parches

Lee la corrección, no solo el informe original del error. Los parches de seguridad suelen ser más limitados que el problema que pretenden resolver. Un parche puede cerrar la vía notificada, pero dejar abierta una vía adyacente. Entender qué cambia una corrección —y, lo que es igual de importante, qué no cambia— es una de las formas más fiables de descubrir vulnerabilidades relacionadas.

Revisión manual del código frente a los escáneres

Usa escáneres para encontrar patrones; confía en la revisión del código para entender el comportamiento. Las herramientas automatizadas son eficaces para identificar clases conocidas de problemas, pero mucho menos eficaces a la hora de detectar fallos en la lógica, la autorización o los límites de confianza. Esas vulnerabilidades suelen existir en la brecha entre lo que hace el código y lo que su autor pretendía que hiciera. Encontrarlas suele requerir leer el código manualmente.

Comprobación de la coherencia

Busca excepciones. En un código maduro, los problemas similares suelen resolverse de forma similar. Cualquier cosa que se salga de esos patrones merece un análisis más detallado: la función que crea su propia consulta en lugar de usar el enfoque compartido; el gestor de solicitudes que se salta un paso de validación; la herramienta que se comporta de forma diferente a sus equivalentes. Estas incoherencias suelen ser el punto en el que las suposiciones fallan y surgen las vulnerabilidades.

No hay nada revolucionario en esto. El hilo conductor de todos estos hábitos es una revisión de código centrada, paciente e intencionada, dirigida especialmente al código que ya se ha «arreglado» y que, por lo tanto, se da por seguro.

Dónde buscar

La selección de objetivos es tan importante como tu técnica de revisión. La mayoría de las bases de código grandes contienen mucho más código del que cualquiera podría examinar en detalle de forma razonable, así que saber dónde centrar tu atención suele marcar la diferencia entre encontrar algo importante y no encontrar nada en absoluto.

Hay algunas áreas que siempre merecen un escrutinio más minucioso. No es porque sean intrínsecamente defectuosas, sino porque tienden a acumular suposiciones, complejidad y confianza con el paso del tiempo.

Código modificado recientemente

Busca código que haya sufrido cambios recientes, sobre todo código al que se le haya aplicado un parche recientemente. Las correcciones recientes pueden introducir nuevas suposiciones, y es posible que esas suposiciones no se hayan formulado a fondo. Un parche puede resolver un problema notificado, pero dejar sin explorar otras vías relacionadas.

Lógica de autorización y permisos

La lógica de autorización —quién puede hacer qué, a quién y en qué condiciones— es muy difícil de modelar. Las herramientas automatizadas rara vez la entienden bien, y los desarrolladores pueden implementarla de forma diferente cada vez. Esto hace que el código de autorización sea una fuente frecuente de vulnerabilidades sutiles.

Puntos de integración

Los puntos de integración son los límites en los que un sistema debe confiar en la información que le proporciona otro sistema —donde los datos pasan de ser no fiables a fiables—. A veces, esta transición ocurre sin una decisión explícita o un paso de validación que justifique esa confianza, lo que deja margen para que surjan vulnerabilidades sin control.

Ninguna de las áreas anteriores es oscura. Son, principalmente, los puntos en los que la brecha entre lo que el código pretendía hacer y lo que realmente hace es más amplia.

CVE-2026-54358: un análisis de principio a fin

Hay un ejemplo público que ilustra cómo funcionan conjuntamente estos hábitos de revisión recomendados. Se trata de una vulnerabilidad sencilla en una aplicación web, sin relación con áreas más recientes como la seguridad de la IA, porque el método es más importante que el objetivo.

MISP es una plataforma de inteligencia sobre amenazas de código abierto muy utilizada. Una corrección reciente para una vulnerabilidad de autorización, CVE-2026-44380, había reforzado los límites de privilegios al impedir que los administradores de la organización con menos privilegios tuvieran acceso a las cuentas de administrador del sitio.

Desde una perspectiva de seguridad ofensiva, ese tipo de corrección es una pista más que un caso cerrado. Establece una regla sobre quién puede actuar con una cuenta de administrador del sitio, lo que plantea una pregunta sencilla: ¿se aplica esa regla en todos los sitios donde debería?

En la mayoría de las rutas administrativas, sí se aplicaba. Sin embargo, había una que destacaba. El código responsable del correo electrónico administrativo, incluida una acción opcional de restablecimiento de contraseña, ejecutaba su propia consulta de usuarios en lugar de aplicar el mismo límite de la misma manera. Filtraba a los destinatarios por organización, pero nunca excluía las cuentas con el rol de administrador del sitio. Tanto el análisis de las lagunas en los parches como la comprobación de la coherencia apuntaban a la misma ubicación: una ruta a la que la corrección anterior no había llegado y que se comportaba de forma diferente al código que la rodeaba.

Antes de informar del fallo, reproduje el problema en una instancia local temporal propia, utilizando cuentas de prueba seguras creadas específicamente para la validación. Ese paso es importante: existe una prueba de concepto para disipar dudas y nunca debe involucrar sistemas o datos que pertenezcan a otros.

En la práctica, la vulnerabilidad permitía a un administrador de la organización activar un restablecimiento de contraseña para una cuenta de administrador del sitio dentro de la misma organización, una que se situaba por encima de él en el modelo de privilegios. El aviso público describe el impacto confirmado como una interferencia en esa cuenta con privilegios superiores. Si se da una condición adicional, como la interceptación del correo electrónico de restablecimiento en una infraestructura de correo compartida o mal configurada, esa interferencia podría derivar en la apropiación de la cuenta.

El problema se notificó al equipo coordinador del proyecto y posteriormente se publicó como CVE-2026-54358 con una puntuación CVSS v4.0 de 7,5 (Alta). Aquí no se proporciona ningún exploit funcional; el aviso público contiene la información necesaria para quienes la necesiten.

El hallazgo no requirió corrupción de memoria, ni ninguna técnica de explotación novedosa, ni «buena suerte». Surgió al leer detenidamente una corrección conocida y preguntarse si estaba realmente completa. La vulnerabilidad no estaba oculta; existía en la única ruta a la que la corrección original nunca había llegado.

Otros proyectos que utilizan este enfoque

La mayor parte de mi investigación actual en este ámbito se ha centrado en la capa en la que los agentes de IA se conectan a sistemas reales: los servidores del Protocolo de Contexto de Modelo (MCP) y los kits de desarrollo de software (SDK) que los proveedores están lanzando al mercado a gran velocidad. Se repiten los mismos hábitos, y han dado lugar a CVE reconocidas por los proveedores en varios proyectos importantes:

• dbt-mcp de dbt Labs: Tres problemas notificados, entre ellos la inyección de argumentos en los envoltorios de herramientas CLI (CVE-2026-44968, CVSS 6.3) y dos casos en los que argumentos sensibles de las herramientas podían llegar a los registros o a la telemetría sin ser ocultados (CVE-2026-44969 y CVE-2026-44970).
• Servidor MCP de GitHub: Un problema de confusión de estado entre usuarios en el modo de bloqueo (CVE-2026-48529), notificado de forma independiente.
• SDK de Python de MCP de Anthropic: Un transporte HTTP que gestionaba solicitudes de sesión sin comprobar el principal autenticado (CVE-2026-52869, CVSS 7.1), notificado de forma independiente.
• MCP Toolbox for Databases de Google: Una omisión de autorización en la que se saltaban las comprobaciones de ámbito por herramienta en versiones antiguas del protocolo (CVE-2026-11719, CVSS 8.6).
• Servidor MCP de Contentful: Herramientas de exportación e importación que pasaban un parámetro de host controlado por LLM al cliente de gestión, lo que permitía redirigir el token de acceso del servidor a un endpoint controlado por el atacante (CVE-2026-53957, CVSS 7.7).

Ninguno de estos hallazgos surgió de un análisis a gran escala ni de una herramienta hecha a medida. Son el tipo de problemas que salen a la luz cuando se aplican los mismos hábitos de revisión de forma cuidadosa y sistemática, proyecto a proyecto. Cada uno se notificó de forma privada y se corrigió mediante el proceso de divulgación responsable.

(Los valores CVSS son las puntuaciones base publicadas en los avisos correspondientes).

Informar es la mitad del trabajo

Encontrar una vulnerabilidad es solo una parte del proceso. Convertir los hallazgos en correcciones requiere un informe que permita a los mantenedores actuar rápidamente. Redactar ese informe es una habilidad en sí misma.

Los informes eficaces minimizan el tiempo que transcurre entre la lectura y la reproducción del fallo. Un resumen conciso, la ubicación precisa en el código, las condiciones necesarias para provocar el problema y una prueba de concepto mínima compartida de forma privada suelen ser suficientes para que un mantenedor confirme un hallazgo en cuestión de minutos. Las evaluaciones de gravedad son útiles, pero hay que tomárselas con cautela. Los responsables del mantenimiento pueden aportar contexto de implementación o detalles de la implementación que modifiquen el impacto en la práctica. El objetivo no es conseguir la puntuación más alta posible, sino la más precisa. Con el tiempo, una reputación de informar con claridad y de buena fe vale más que cualquier puntuación CVSS individual.

La paciencia es igual de importante. La divulgación responsable significa dar a los proveedores una oportunidad razonable para investigar y solucionar un problema antes de que los detalles se hagan públicos, hacer un seguimiento profesional cuando las conversaciones se estancan y publicar solo una vez que haya una solución disponible o haya pasado el plazo de divulgación acordado.

Rara vez es el enfoque más rápido. Sin embargo, es el que mejor sirve a los mantenedores, a los usuarios y a la comunidad de seguridad.

Por qué es importante más allá del gestor de errores

Puede resultar tentador ver una lista de CVE como una recopilación de exploits ingeniosos o técnicas novedosas. En realidad, muchas vulnerabilidades surgen de errores mucho más comunes: una comprobación de roles errónea, una entrada no fiable que se pasa sin validar o una corrección a la que le falta una línea. Son los mismos tipos de vulnerabilidades que los equipos de seguridad de aplicaciones llevan décadas abordando.

Lo que ha cambiado es el alcance del impacto. En cuanto una organización concede a los agentes de IA acceso a sus bases de datos, repositorios y sistemas de contenido, la capa de integración hereda todos los errores y vulnerabilidades existentes, al tiempo que adquiere un nuevo desencadenante: contenido no fiable que puede impulsar el comportamiento de un agente. Una comprobación de autorización que falta ya no solo es accesible para un usuario autenticado que navega por una aplicación. También puede ser accesible a través del contenido que se le ha pedido a un agente que lea, procese o sobre el que actúe.

La superficie de ataque se amplía en consecuencia. Puede que un atacante ni siquiera necesite una cuenta, una sesión de navegador o acceso directo a una aplicación. Puede que baste con colocar contenido cuidadosamente elaborado donde un agente lo encuentre. Eso amplía el abanico de amenazas que las organizaciones deben tener en cuenta y aumenta el coste de cada brecha de autorización que se deje sin resolver.

Imagina a un agente al que se le pide que resuma un documento compartido o que clasifique una bandeja de entrada. Si una línea de ese contenido se puede interpretar como una instrucción, y el agente puede actuar en función de lo que lee, entonces un texto no fiable puede influir en el agente para que utilice cualquier permiso que tenga.

Por suerte, muchas de las mismas técnicas recomendadas para la revisión de código siguen siendo válidas en estos contextos. Las vulnerabilidades subyacentes rara vez son complicadas. Siguen siendo cuestiones de confianza, límites, validación y autorización: el tipo de problema que una revisión minuciosa del código fuente siempre ha sabido detectar.

Qué revisar en tu propio código

Todos los hábitos de revisión de código de este artículo son útiles para encontrar vulnerabilidades, pero también lo son para prevenirlas. Para los responsables del mantenimiento, ofrecen una serie de preguntas que vale la pena plantearse con regularidad. Esto es lo que debes tener en cuenta.

Cuando se implemente una corrección de seguridad, trátala como el comienzo de una revisión en lugar de como el final de la misma. ¿Ha comprobado alguien si el mismo error existe en otro sitio —en una función hermana, una ruta de código paralela u otro componente que la corrección no haya tocado? El código recién parcheado suele ser uno de los terrenos más fértiles para la revisión, precisamente porque la gente da por sentado que es seguro.

Cuando se introduzca un control de seguridad compartido, comprueba que se aplique en todos los sitios donde deba estar. No basta con que la regla exista; debe aplicarse de forma coherente. Un límite aplicado a seis funciones, pero que falta en la séptima, sigue siendo una vulnerabilidad aunque la regla exista técnicamente.

Trata las llamadas a herramientas generadas por IA con el mismo escepticismo que aplicarías a cualquier otra entrada no fiable. Si un modelo puede verse influenciado por el contenido que lee, cualquier cosa que produzca también puede verse influenciada. Parámetros como los nombres de host, las rutas de archivo y los fragmentos de consulta merecen el mismo escrutinio que los datos enviados a través de un formulario web.

Por último, presta mucha atención a las uniones entre sistemas. La confianza suele acumularse poco a poco a medida que los datos pasan de un componente a otro. El punto en el que los datos no fiables pasan a ser fiables no siempre es explícito, y suele ser ahí donde las suposiciones de seguridad empiezan a fallar.

Aplicar estas ideas al trabajar con clientes

Todos estos principios se aplican más allá de la investigación de vulnerabilidades. En Sophos, la emulación de adversarios y las pruebas de penetración basadas en amenazas no son simplemente ejercicios que consisten en ejecutar escáneres y revisar los resultados. Implican examinar los sistemas tal y como lo haría un atacante: siguiendo los límites de confianza, cuestionando las suposiciones y analizando de cerca las rutas que otros han dejado de cuestionar.

Esto cobra aún más importancia a medida que las organizaciones conectan agentes de IA a los sistemas de producción. Cada nueva integración introduce nuevas relaciones de confianza, nuevos flujos de datos y nuevas suposiciones sobre la ruta de influencia. La pregunta clave que debes hacerte ahora no es si esas «costuras» existen, sino si alguien las ha examinado a fondo. Si te cuesta responder a esa pregunta, ya tienes por dónde empezar a buscar.

Las organizaciones y los equipos que se adelanten a estos riesgos serán aquellos que revisen los límites de forma continua, aplicando el mismo escrutinio a las integraciones de la era de la IA que aplicarían a cualquier otra superficie de ataque de alto valor.

Para saber más sobre los servicios MDR de Sophos, haz clic aquí.

Este artículo solo aborda hallazgos que ya se han hecho públicos y documentado.