Un hacker puede interceptar tu tráfico — y eso es solo el comienzo: detectan 84 vulnerabilidades en las redes 5G "inteligentes"

Los mecanismos internos de las redes móviles se construyeron durante décadas sobre la base de la confianza, pero los operadores migraron a la nube y la antigua costumbre arquitectónica se convirtió en la fuente de decenas de vulnerabilidades. Especialistas de la Universidad Tecnológica Nanyang encontraron 84 defectos hasta ahora desconocidos en el software de los núcleos de redes 4G y 5G. Los desarrolladores ya confirmaron 83 hallazgos, y 81 recibieron un número CVE.

Los problemas se detectaron en siete implementaciones abiertas del núcleo móvil, incluyendo Open5GS, free5GC, OpenAirInterface, SD-Core y eUPF. Las vulnerabilidades afectaron a los protocolos GTP-C y PFCP, a través de los cuales los componentes internos de la red crean sesiones de comunicación, transmiten datos y establecen reglas de enrutamiento.

La causa de la mayoría de los errores no está en un fragmento puntual de código, sino en el modelo general de seguridad. Los componentes del núcleo móvil suelen asumir que los mensajes de nodos vecinos son correctos por defecto. Por ello, los programas pueden no comprobar campos obligatorios, la longitud de los datos, los valores permitidos o la disponibilidad de recursos. Esa lógica surgió en una época en la que las interfaces internas funcionaban en una infraestructura físicamente aislada y apenas se relacionaban con redes externas.

Los sistemas en la nube han debilitado esa barrera anterior. Un error en la configuración de la red o una infraestructura insuficientemente aislada pueden exponer las interfaces internas a un atacante. En algunos casos, los mensajes de control maliciosos también se pueden ocultar dentro del tráfico de usuarios normal y pasar por la estación base hasta los componentes del núcleo.

Los autores denominaron a esta clase de problemas errores de confianza implícita. Entre las 84 vulnerabilidades, las situaciones más habituales eran aquellas en las que el programa esperaba un campo obligatorio pero no comprobaba su existencia. Otros errores permitían transmitir valores incorrectos, romper el estado de la conexión o agotar reservas internas de memoria y objetos de control. Por ello, ciertos componentes de la red dejaban de funcionar y dejaban de atender solicitudes.

Para buscar esos defectos, los especialistas crearon un sistema multiagente llamado iFinder basado en un modelo de lenguaje grande. Primero, el sistema extrae patrones recurrentes de errores conocidos, luego analiza el código fuente y compara las secciones sospechosas con las especificaciones 3GPP. A continuación iFinder genera automáticamente código demostrativo, lo ejecuta en un entorno de pruebas y lo ajusta según los registros de ejecución hasta confirmar la vulnerabilidad o agotar el número de intentos.

Cuando el modelo de lenguaje se limitaba a revisar el código sin pasos adicionales, ello producía demasiados falsos positivos. Tras verificar los resultados con las especificaciones y realizar pruebas prácticas, la precisión de iFinder aumentó del 28% al 75%. El sistema reconoció alrededor del 68% de las vulnerabilidades conocidas de antemano que se utilizaron para validar el método.

El hallazgo más peligroso fue un caso en el que un atacante pudo interceptar una sesión de comunicación. El atacante podía enviar una solicitud PFCP falsa y añadir una regla con prioridad más alta que la configuración legítima del abonado. El nodo que procesaba el tráfico de usuario aceptaba un identificador repetido sin verificarlo y comenzaba a reenviar los datos salientes de la víctima al atacante en lugar de a Internet.

Los especialistas reprodujeron el ataque no solo en la implementación abierta, sino también en dos núcleos comerciales 5G con configuraciones por defecto. Un proveedor ya corrigió el fallo registrado como CVE-2026-8233 (4.6 Medium). Otro operador, en el momento de la publicación, seguía preparando la corrección. Otra vulnerabilidad confirmada en un sistema comercial recibió el número CVE-2026-8232 (3.5 Low) y permitía causar una denegación de servicio.

Los autores aconsejan a los operadores no confiar ciegamente en todo lo que está dentro del núcleo móvil, segregar estrictamente los componentes de la red y cerrar el acceso innecesario a las interfaces de control. A los desarrolladores les recomiendan comprobar la estructura y el sentido de cada mensaje, prohibir identificadores de reglas repetidos y limitar los recursos asignados, de modo que una solicitud incorrecta provoque un rechazo y no detenga todo el servicio.