NatJack: compartir tabla NAT con un desconocido ya no sale gratis

Un vistazo en 30 segundos

• NatJack es una clase de ataques contra NAT presentada en Black Hat USA 2026 por Malcolm Stagg, del Synack Red Team.
• Reúne cuatro técnicas: secuestro de conexiones TCP, envenenamiento de respuestas DNS, descubrimiento del puerto asignado a otra conexión y agotamiento de la tabla NAT.
• El atacante solo necesita estar detrás del mismo NAT que la víctima con privilegios en su propio sistema. No hace falta spoofing de capa 2 ni compartir dominio de broadcast.
• Trabaja en capas 3 y 4, así que la separación por VLAN y el aislamiento de puertos de switch no lo frenan.
• Se probaron 32 productos y configuraciones de 13 fabricantes, con 95 informes. Todos resultaron vulnerables a alguna de las técnicas.
• Dos CVE públicas: CVE-2026-56181 (NAT de Windows en Hyper-V, CVSS 8,3) y CVE-2026-63913 (netfilter conntrack en Linux, CVSS 8,2). Synack sitúa el conjunto de sus hallazgos entre 7,2 y 9,6.
• No hay un parche universal: es una suposición de diseño, no un error de código concreto. La mitigación real es arquitectónica.

---

Hay tecnologías que envejecen sin que nadie las revise porque funcionan. NAT es el ejemplo perfecto: nació para estirar un espacio de direcciones IPv4 que se quedaba corto, resolvió el problema y se quedó ahí, en el sitio donde se le dejó, mientras alrededor cambiaba todo lo demás. Hoy hay NAT dentro de hipervisores, hosts de contenedores, clústeres de Kubernetes, gateways cloud, firewalls y bridges virtuales. Y en muchos de esos sitios, la misma tabla gestiona conexiones de cargas que no tienen nada que ver entre sí.

Eso es lo que ha ido a mirar Malcolm Stagg, investigador de SODIUM-24 y miembro del Synack Red Team, en un trabajo de varios años que presentó el 6 de agosto en Black Hat USA 2026 con el título Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure. El resultado se llama NatJack y no es una vulnerabilidad de un router. Es una forma de atacar el propio funcionamiento del NAT, y aparece en implementaciones de Windows, Linux y macOS que no comparten una sola línea de código.

La suposición que ya no se sostiene

Cuando una máquina con dirección privada abre una conexión hacia Internet, el dispositivo que hace NAT reescribe dirección y puerto de origen, y guarda esa traducción para saber a quién devolver las respuestas. Necesita mantener estado: qué flujos hay vivos, en qué punto de la máquina de estados de TCP están, qué puerto externo se le asignó a cada uno. En Linux ese trabajo lo hace netfilter conntrack; en Windows, el NAT que usan Hyper-V y el resto de tecnologías de virtualización; en macOS, lo suyo.

Para que ese mecanismo sea cómodo de usar, las implementaciones son permisivas. Aceptan paquetes que no encajan del todo con el estado que tienen guardado, reutilizan puertos de forma predecible, mantienen mapeos que valen para más de un destino. Nada de eso es un fallo: es lo que hace que funcionen las videollamadas, los juegos y cualquier cosa que necesite atravesar dos NAT a la vez.

El propio Stagg lo resume apuntando a los RFC: hay comportamientos poco especificados que se dieron por buenos «asumiendo que estás en una red donde los pares son de confianza». Esa premisa aguantó tres décadas. En un host que ejecuta cien contenedores de clientes distintos, o en un gateway NAT cloud compartido, deja de aguantar.

Cuatro técnicas, un mismo punto de apoyo

Las cuatro comparten requisito: el atacante tiene que estar detrás del mismo NAT que la víctima, con privilegios suficientes en su propio sistema para fabricar paquetes a medida. No necesita ver el tráfico ajeno ni estar en el mismo segmento de capa 2, que es justo lo que diferencia esto de los ataques clásicos de red local.

El secuestro de TCP es el que más ruido ha hecho, y tiene un detalle bonito. Para adueñarse de la entrada de la tabla hay que echar antes a la conexión legítima, y esperar a que expire un TIME-WAIT normal sería inviable en la práctica. Stagg tira de TIME-WAIT Assassination, el comportamiento descrito en el RFC 1337 allá por 1992, que permite hacerlo en un puñado de paquetes. Un documento de hace treinta y cuatro años convertido en acelerador de un ataque de 2026.

Conviene matizar qué significa «secuestrar». Controlar el flujo TCP no rompe el cifrado que viaje por encima: si la sesión es TLS, el atacante puede quedarse con el canal, pero no con el contenido, y el cliente verá fallar la validación del certificado. El problema serio está en todo lo que sigue viajando en claro dentro de las redes privadas porque «total, es interno».

El envenenamiento de DNS es otra historia. Si el resolver acepta una respuesta manipulada, el dominio se resuelve hacia donde quiera el atacante y a partir de ahí da igual lo bien montado que esté el resto. Y el agotamiento de la tabla no necesita ni sutileza: llenas conntrack de flujos falsos y nadie más establece conexiones nuevas.

Escala del problema: todo lo que se probó falló

La parte que más dice sobre la naturaleza del asunto no son las CVE, sino el recuento del trabajo de campo. Stagg notificó a 13 fabricantes, probó 32 productos y configuraciones, produjo 95 informes y desarrolló siete pruebas de concepto más variantes específicas por producto. Todos los productos probados resultaron vulnerables a alguna de las técnicas, o a todas.

De ahí han salido por ahora dos identificadores públicos:

Ojo con una cifra que circula mal por ahí. Synack habla de puntuaciones entre 7,2 y 9,6 para el conjunto de lo que reportó, de severidad alta a crítica, pero eso no son las notas de estas dos CVE: son 8,3 y 8,2. La divulgación coordinada sigue abierta y pueden aparecer más avisos.

También hay parche en FreeBSD 15.0 y posteriores. Y la fecha de las correcciones de Linux merece una nota al margen, porque el reporte inicial se rechazó como «totalmente falso» y acabó parcheándose después. En el caso de Microsoft, según se ha publicado, el arreglo llegó tras la petición del equipo de Azure Kubernetes Service.

Cisco y Apple dicen que no es un fallo

Aquí está lo que de verdad separa a NatJack de una vulnerabilidad al uso. Dos de los fabricantes notificados han declinado tratarlo como problema de seguridad: Cisco lo clasifica como limitación de diseño de NAT a nivel de sistema, con mitigaciones ya documentadas, y Apple considera que el comportamiento refleja una limitación conocida de la capa de transporte.

No es una postura absurda. Si el estándar nunca dijo lo contrario y la implementación hace lo que el estándar permite, técnicamente no hay nada roto. El problema es que esa respuesta deja al administrador con un comportamiento explotable, sin CVE al que agarrarse y sin parche que instalar. Y como el fallo es de comportamiento y no de firma, es probable que tu escáner de vulnerabilidades habitual no te diga nada al respecto.

Esa es la incomodidad de fondo: la conversación se traslada del boletín de seguridad al diseño de la red, que es un sitio donde arreglar cosas cuesta bastante más que aplicar una actualización.

Por qué esto va de multi-tenant y no de tu router de casa

En una red doméstica o en una oficina pequeña, todo lo que hay detrás del NAT pertenece a la misma organización. Si un atacante ya tiene privilegios en una de esas máquinas tienes un problema mucho más gordo que NatJack.

El escenario que importa es otro: un host físico con decenas o cientos de máquinas virtuales y contenedores de clientes distintos, un clúster de Kubernetes compartido entre equipos, un servicio que ejecuta código de terceros o un gateway NAT cloud al que cuelgan cargas de varios proyectos. Synack señala explícitamente routers y firewalls, Docker, Kubernetes, Hyper-V, gateways NAT cloud, bridges y switches virtuales y los servicios públicos de contenedores y virtualización.

La pregunta que hay que hacerse es concreta, y se responde en una tarde:

¿Puede una carga controlada por alguien en quien no confío compartir la misma infraestructura NAT que un sistema sensible?

Si la respuesta es que sí, tienes trabajo. Si es que no, esto es una actualización más de la cola de parches.

Y hay un detalle que estropea el consuelo habitual. Mucha gente responde a esa pregunta diciendo que sus cargas están separadas por VLAN. La separación de capa 2 no sirve aquí, porque el ataque va contra la tabla NAT compartida, en capas 3 y 4. Dos VLAN distintas que salen por el mismo gateway NAT siguen compartiendo el punto que se ataca. Lo mismo ocurre con el aislamiento de puertos de switch. Es un buen momento para releer cómo se plantea la microsegmentación de red con SDN y firewall y comprobar dónde acaba realmente cada frontera.

Conntrack: de métrica de rendimiento a señal de seguridad

Para quien administra Linux, el componente a vigilar es conntrack. El kernel expone los parámetros de siempre:

# Entradas en uso y máximo permitido
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_buckets

# Seguimiento laxo de TCP: con 1 acepta flujos cuyo inicio no ha visto
sysctl net.netfilter.nf_conntrack_tcp_loose

nf_conntrack_count frente a nf_conntrack_max es la relación que todo el mundo mira cuando algo va lento y nadie mira cuando todo va bien. Un host que se acerca al límite sin motivo aparente no tiene por qué estar mal dimensionado: puede estar sufriendo el agotamiento deliberado de la tabla, que es la cuarta técnica de NatJack.

nf_conntrack_tcp_loose es el otro que conviene revisar. Con el valor por defecto a 1, conntrack acepta y sigue conexiones cuyo establecimiento no ha presenciado. Es cómodo en escenarios de rutas asimétricas y es justo el tipo de permisividad del que se aprovechan estas técnicas. Ponerlo a 0 rompe algunos casos legítimos, así que se prueba antes de tocarlo en producción, pero en un gateway que da servicio a cargas que no se conocen entre sí es una decisión razonable.

Si ya tienes monitorización con Prometheus y Grafana, las métricas de conntrack probablemente estén recogidas y sin alerta asociada. Ese es el cambio de mentalidad que propone esta investigación: mirar la ocupación de la tabla NAT como un indicador de seguridad y no solo de capacidad, con umbrales, alerta y alguien que la reciba.

Qué hacer, por orden de eficacia

Las actualizaciones son lo primero, pero son la parte fácil y la que menos cubre. Lo que de verdad reduce el riesgo tiene más que ver con dónde pones cada cosa.

Sobre el cifrado interno merece la pena insistir, porque es donde más se nota la herencia cultural. TLS hacia Internet se da por hecho, pero dentro de la red privada todavía hay bases de datos, colas de mensajes, APIs internas y sistemas de ficheros hablando en claro porque «están dentro». NatJack es un argumento más, y bastante bueno, para terminar ese trabajo pendiente. Ya lo era la microsegmentación y lo era el modelo de confianza cero.

Cómo lo vemos desde cloudprivado.com

Nos dedicamos a diseñar infraestructura de cloud privado con hardware dedicado, así que esta investigación nos toca de lleno, pero por una vía distinta a la del titular.

En un cloud privado bien planteado, las máquinas virtuales de un cliente no comparten host, ni bridge, ni gateway de salida con las de otro. No es una medida antiNatJack, es cómo se hace desde siempre: recursos dedicados, VLAN propias, direccionamiento propio y salida a Internet con IP pública asignada al cliente, sin pasar por una tabla de traducción que también usen terceros. La diferencia con un entorno compartido no es de configuración, es de dónde vive cada carga.

Eso no nos deja fuera del asunto. Dentro de un mismo cliente también hay niveles de confianza distintos, y ahí sí hay que sentarse a mirar. El caso típico es la plataforma de contenedores que ejecuta código de un pipeline de CI, o el entorno de desarrollo que comparte gateway con producción porque en su día era lo cómodo. Como ya vimos con Leaky Vessels en runc y Docker, la frontera del contenedor da menos de lo que la gente cree, y este trabajo añade que la del NAT tampoco es una frontera.

Tres cosas que sí conviene preguntarle a cualquier proveedor, incluidos nosotros:

1. ¿Mis cargas comparten infraestructura NAT con las de otros clientes? Si la respuesta tarda en llegar o se responde con «cada cliente tiene su VLAN», la pregunta no se ha entendido.
2. ¿Qué salida a Internet tienen mis máquinas? IP pública directa, NAT dedicado y NAT compartido son tres respuestas con tres perfiles de riesgo distintos. También con tres costes distintos, que es de lo que hablábamos en NAT ya no es gratis.
3. ¿Quién vigila la ocupación de las tablas de conexiones y qué pasa si se llenan? Es la pregunta que separa una monitorización de escaparate de una que sirve.

Y una reflexión de fondo que va más allá de esta investigación concreta. Buena parte de esto existe porque seguimos estirando IPv4 con traducciones sucesivas donde IPv6 daría direccionamiento propio y extremo a extremo sin tabla compartida que atacar. No es la solución mágica y trae sus propios deberes de filtrado, pero es otra razón para no dejar el direccionamiento IPv6 en el cajón de pendientes eternos.

Lo que queda claro

NAT no está roto ni hay que retirarlo. La conclusión de Stagg es más específica y bastante más útil: NAT no es una frontera de seguridad entre cargas que no confían unas en otras, y llevamos años tratándolo como si lo fuera.

En 1996 esa confusión era barata, porque detrás de una tabla NAT estaban los ordenadores de una misma oficina. En 2026, detrás de la misma tabla puede haber el contenedor de un cliente y la base de datos de otro. La tecnología no ha cambiado; lo que ha cambiado es quién está sentado al otro lado, y ese matiz se llevaba tiempo sin revisar.

Preguntas frecuentes

¿Qué es NatJack exactamente? Una clase de ataques descrita por Malcolm Stagg (Synack Red Team) que aprovecha comportamientos y suposiciones de confianza de las implementaciones de NAT. Agrupa cuatro técnicas: secuestro de conexiones TCP, envenenamiento de respuestas DNS sobre UDP, descubrimiento del puerto externo asignado a otra conexión y agotamiento de la tabla NAT. Se presentó el 6 de agosto de 2026 en Black Hat USA.

¿Qué sistemas están afectados? Las pruebas encontraron comportamientos explotables en implementaciones desarrolladas de forma independiente para Windows, Linux y macOS, sobre 32 productos y configuraciones de 13 fabricantes. El riesgo real depende de la implementación, la configuración y, sobre todo, de si hay cargas de confianza distinta compartiendo el mismo NAT.

¿Qué CVE hay asignadas y con qué gravedad? CVE-2026-56181, en el NAT de Windows que usa Hyper-V, con CVSS 8,3, y CVE-2026-63913, en el subsistema netfilter conntrack de Linux, con CVSS 8,2. Synack sitúa el conjunto de los problemas que reportó entre 7,2 y 9,6, de alta a crítica, y la divulgación coordinada continúa.

¿Me protege separar las cargas en VLAN distintas? No, si esas VLAN salen por el mismo gateway NAT. El ataque trabaja en capas 3 y 4 contra la tabla de traducción compartida, así que ni la separación por VLAN ni el aislamiento de puertos de switch lo detienen. Lo que corta el vector es no compartir la infraestructura NAT entre niveles de confianza distintos.

¿Basta con actualizar? Ayuda y hay que hacerlo, pero no cierra el asunto. Las actualizaciones disponibles aumentan la complejidad del ataque o reducen la viabilidad de algunas técnicas; no eliminan la suposición de diseño de fondo. Synack cita el kernel de Linux 6.6.142 y posteriores y FreeBSD 15.0 y posteriores, además de los boletines de Microsoft. Cisco y Apple han decidido no tratarlo como vulnerabilidad.

¿Cómo detecto si me está pasando? No hay firma que buscar, porque es comportamiento y no un exploit reconocible. Lo que se puede vigilar es la ocupación de las tablas NAT y de conntrack, los picos de conexiones sin causa conocida y los patrones anómalos de paquetes. Un escaneo de vulnerabilidades convencional probablemente no te diga nada.

¿Afecta a un clúster de Kubernetes cualquiera? No automáticamente. Afecta si en ese clúster hay cargas de confianza distinta compartiendo componentes NAT, que es lo habitual en plataformas multiequipo, en servicios que ejecutan código de terceros y en clústeres gestionados de cloud público. Un clúster con cargas de un solo equipo y sin código externo tiene un perfil de riesgo muy inferior.

Fuentes

• Synack, New NatJack Research Exposes Design Weaknesses Across Major NAT Implementations, 6 de agosto de 2026.
• Synack Security Research, NatJack: NAT Attack Class.
• Black Hat USA 2026, Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure, Malcolm Stagg.
• The Hacker News, New NatJack Attacks Hijack TCP Sessions and Spoof DNS by Manipulating NAT Tables.
• CSO Online, NatJack exploits put NAT security assumptions to the test at Black Hat.
• Network World, NatJack at Black Hat: A new way to crack NAT’s trust gap.
• IETF, RFC 1337: TIME-WAIT Assassination Hazards in TCP.
• Documentación del kernel de Linux, parámetros nf_conntrack de netfilter.

---

¿Tienes cargas sensibles compartiendo infraestructura de red con entornos de desarrollo, pipelines de CI o código de terceros? Revisamos contigo dónde están de verdad las fronteras de tu arquitectura y qué hace falta para separarlas. Empieza por la ciberseguridad gestionada o hablemos de tu proyecto.