Un equipo de investigación de la Universidad Tecnológica Nanyang (Singapur) ha publicado un estudio que describe vulnerabilidades en núcleos 4G y 5G con potencial para causar denegación de servicio (DoS) y, en escenarios concretos, session hijacking. El trabajo se centra en fallos que pueden aparecer cuando diferentes componentes del núcleo de la red interactúan bajo un modelo de confianza que se debilita en despliegues modernos.
El informe, titulado Understanding Implicit Trust Errors in Core Carrier Networks through Multi-Agent Flaw Discovery and Analysis, pone el foco en errores que los investigadores han denominado implicit trust errors (iTrues). En la práctica, estos problemas surgen cuando las funciones del núcleo aceptan mensajes de otras funciones sin una validación estricta de formato, semántica y disponibilidad de recursos.
¿Qué significa “confianza implícita” en el núcleo móvil?
Tradicionalmente, muchos núcleos celulares han contado con aislamiento físico para limitar el acceso entre funciones y mantenerlas dentro de una “zona de confianza”. Sin embargo, el paso a arquitecturas cloud-native ha cambiado el panorama: se amplía la superficie de ataque y pueden volverse alcanzables interfaces que antes permanecían internas.
Según el estudio, existe un patrón recurrente: una “confianza ciega” entre componentes. Cuando además hay debilidades en las interfaces de señalización, un actor externo —o incluso un equipo de usuario malicioso— podría explotar esas rutas para provocar actividades maliciosas. Entre los efectos descritos están la interrupción del servicio y el secuestro de sesiones.
Qué se investigó: interfaces de señalización en 4G y 5G
El análisis cubre vulnerabilidades en interfaces de señalización de redes de núcleo LTE/5G. Para aterrizar el trabajo en implementaciones reales, los investigadores estudiaron dos núcleos LTE de código abierto —Open5GS y OpenAirInterface— y cinco implementaciones de 5G: Open5GS, free5GC, OpenAirInterface, SD-Core y eUPF.
Los hallazgos abarcan dos protocolos de control del núcleo: GTP-C (GPRS Tunnelling Protocol Control Plane) y PFCP (Packet Forwarding Control Protocol). Es decir, se revisaron puntos donde la red decide cómo señalizar, crear sesiones y coordinar la función de plano de usuario.
Un método automatizado para descubrir nuevos fallos
Para detectar iTrues y entender sus consecuencias, el estudio desarrolló un sistema multiagente asistido por un modelo de lenguaje de gran tamaño (LLM) llamado iFinder. La idea era resumir fallos conocidos, clasificarlos y usarlos como base para localizar errores similares en el código de las implementaciones.
En fases posteriores, el proceso intenta reducir ruido: se eliminan hallucinations y false positives mediante una técnica de verificación cruzada con especificaciones de código. Después, se emplea el enfoque guiado por LLM para generar pruebas de concepto (PoC) de posibles iTrues y ajustar iterativamente los resultados ejecutándolos contra implementaciones del núcleo y examinando el comportamiento.
Para confirmar que un candidato era un iTrue real, los investigadores describen una lógica adicional: mapear el fallo candidato con el procedimiento del protocolo que implementa y verificar si, en la base de código, existen realmente las validaciones y comprobaciones de recursos necesarias.
Resultados: 84 vulnerabilidades nuevas y confirmadas
Tras ejecutar el agente contra siete implementaciones de núcleos 4G/5G de código abierto, el equipo descubrió 84 vulnerabilidades previamente desconocidas. De ellas, 83 ya fueron confirmadas y 81 recibieron identificadores CVE.
Además, el estudio señala que algunos fallos en sistemas 5G se habrían heredado de contrapartes 4G. Esta idea refuerza un mensaje clave: los riesgos no siempre “se resuelven” al cambiar de generación, porque ciertos patrones de diseño pueden trasladarse a despliegues nuevos. Si el software se moderniza sin revisar cómo opera la confianza entre componentes, pueden aparecer problemas que no estaban contemplados.
DoS: cómo una falla en GTP puede tumbar el núcleo
El estudio describe un escenario hipotético de DoS contra Open5GS LTE. En ese caso, un atacante podría enviar mensajes GTPv2-C orientados a provocar el fallo durante el parsing de solicitudes específicas, en particular los mensajes Create Session Request.
Como resultado de la explotación, el Serving Gateway Control plane (SGW-C) podría crashear. Aunque el ejemplo es hipotético, sirve para ilustrar el impacto potencial cuando el núcleo procesa mensajes de control bajo validaciones insuficientes.
Session hijacking: secuestro de tráfico mediante PFCP y reglas de reenvío
Donde el informe es más contundente es en el riesgo de session hijacking asociado a iTrues de PFCP en escenarios donde el atacante obtiene capacidad para alcanzar interfaces internas del núcleo.
El flujo descrito requiere varios pasos:
- El atacante envía una PFCP Association Setup Request a la User Plane Function (UPF).
- La víctima inicia un “attach”, lo que provoca que el SMF envíe una PFCP Session Establishment Request hacia la UPF.
- Luego, el atacante emite una PFCP Session Modification Request que reutiliza el PDR ID de la víctima con un valor de Precedence menor (o sea, mayor prioridad) y lo asocia a una Forwarding Action Rule (FAR) maliciosa.
- La UPF admite el PDR duplicado y ordena las reglas por precedencia, colocando la regla maliciosa antes que la legítima.
- Durante el procesamiento, la UPF coincide primero con el PDR malicioso y establece un túnel de reenvío hacia el atacante.
- Así, el tráfico ascendente (uplink) del usuario víctima se enruta hacia el atacante en lugar de hacia Internet.
A nivel conceptual, el estudio resume este defecto como la capacidad de inyectar una modificación de sesión para que la UPF redirija el tráfico del usuario hacia un destino controlado por el atacante.
Consecuencias prácticas para la víctima y el operador
Según explicaciones del autor del estudio Ziyu Lin, la vulnerabilidad no solo permitiría observar tráfico del usuario; también podría redirigirlo hacia un endpoint GTP-U bajo control del atacante. Con esa posición, el atacante puede decidir qué hacer con los paquetes: inspeccionarlos, modificarlos, reenviarlos o descartarlos.
Las posibles repercusiones mencionadas incluyen:
- Inspección de tráfico de aplicación, especialmente si hay contenido no cifrado.
- Incluso con cifrado, exposición de metadatos de red (por ejemplo, direcciones de destino, tiempos y volumen de tráfico).
- Manipulación de servicios o tráfico que dependa de protocolos sin protección adecuada (el informe menciona ejemplos como DNS sin protección).
- DoS selectivo: el atacante podría descartar silenciosamente paquetes redirigidos y afectar la conectividad de un suscriptor concreto sin impactar toda la UPF.
Además, el estudio subraya que para que estos ataques funcionen se asume que el atacante puede conseguir direcciones IP de componentes del núcleo (por documentación pública, enumeración pasiva o escaneo activo), y también enviar mensajes PFCP y GTP-C arbitrarios saltándose el modelo de confianza mediante fallos de configuración en despliegues cloud.
Vulnerabilidades en la práctica: correcciones en productos comerciales
El reporte indica que la vulnerabilidad de secuestro de sesión fue encontrada en dos núcleos 5G comerciales. En uno de los casos, el proveedor Dotouch corrigió el defecto en XproUPF, identificado como CVE-2026-8233 con una puntuación CVSS 4.6.
En el segundo caso, correspondiente a un proveedor de 5GC no identificado, el informe señala que el remediado aún estaba en proceso.
El estudio también aclara un punto relevante para el seguimiento de parches: CVE-2026-8233 y CVE-2026-36884 describen el mismo fallo de base en dos productos desarrollados de forma independiente. Por otra parte, CVE-2025-66776 afecta a un producto específico (eUPF) y puede derivar en secuestro de sesión bajo condiciones similares.
Por qué esto es un problema continuo para operadores y proveedores
Los autores rematan con una advertencia: el crecimiento de vulnerabilidades no sugiere errores aislados y puntuales, sino un problema de seguridad más amplio y persistente. En su visión, la situación exige atención urgente por parte de fabricantes y operadores.
El estudio no solo apunta a “un bug”, sino a una clase de fallos relacionada con cómo el núcleo confía en mensajes internos y qué validaciones existen realmente. En un entorno moderno, con interfaces accesibles y componentes desplegados en la nube, esos supuestos de confianza pueden convertirse en el eslabón débil.
Qué pueden hacer equipos de seguridad
Si trabajas en la protección de redes móviles, la lectura del informe sugiere varias líneas de acción: revisar configuraciones para reducir exposición de interfaces de control, verificar que existan validaciones estrictas en el procesamiento de mensajes, y mantener un inventario claro de versiones y parches en funciones del plano de control y de usuario.
También es razonable revisar políticas de segmentación y acceso entre componentes, especialmente en despliegues cloud-native, donde el “perímetro” puede ser más frágil de lo que se asumía en infraestructuras tradicionales.
Conclusión
El estudio deja una conclusión directa: las vulnerabilidades en núcleos 4G y 5G encontradas apuntan a fallos de confianza implícita entre funciones del núcleo y pueden abrir la puerta a daños severos, incluyendo DoS y session hijacking. Con 84 vulnerabilidades nuevas descubiertas y confirmadas en implementaciones evaluadas, el mensaje para operadores y proveedores es claro: no basta con corregir casos aislados; hay que reforzar el modelo de validación y el aislamiento entre componentes en los despliegues actuales.
Fuente: https://thehackernews.com/2026/07/researchers-report-84-flaws-in-4g-and.html
