Una investigación presentada en Black Hat USA 2026 ha identificado NatJack, una nueva clase de ataques contra la traducción de direcciones de red (NAT) capaz de aprovechar comportamientos presentes en implementaciones independientes de Windows, Linux y macOS. El problema no responde a un único fallo de programación: cuestiona una antigua suposición de diseño según la cual los dispositivos y cargas de trabajo que comparten una misma tabla NAT pueden confiar entre sí. Dos vulnerabilidades CVE ya han sido asignadas y las pruebas muestran posibles ataques contra conexiones TCP, DNS y la propia disponibilidad de la red.
Las claves de NatJack en 20 segundos
- NatJack agrupa cuatro técnicas de ataque contra dispositivos que realizan NAT.
- Las pruebas encontraron comportamientos afectados en implementaciones independientes de Windows, Linux y macOS.
- Puede permitir secuestro de conexiones TCP, manipulación de DNS, descubrimiento de puertos y denegación de servicio.
- Existen dos CVE identificadas hasta ahora.
- No hay un parche único que solucione toda la clase de ataques.
La investigación ha sido desarrollada durante varios años por Malcolm Stagg, investigador independiente de SODIUM-24 y miembro del Synack Red Team. Stagg presentó los resultados el 6 de agosto en Black Hat USA bajo el título Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
El alcance potencial resulta especialmente interesante para entornos modernos de infraestructura. NAT no está presente únicamente en el router que conecta una vivienda a Internet. Se utiliza en hipervisores, contenedores, Kubernetes, firewalls, switches virtuales, gateways cloud y plataformas de virtualización, donde numerosas cargas pueden terminar compartiendo mecanismos de seguimiento y traducción de conexiones.
Eso no significa que cualquier dispositivo detrás de NAT pueda ser atacado inmediatamente. La exposición práctica depende, entre otros factores, de que un atacante pueda colocar una carga maliciosa o no confiable en una posición desde la que comparta infraestructura NAT con sistemas que sí son de confianza.
El problema está en una suposición histórica de NAT
Network Address Translation o traducción de direcciones de red nació principalmente como respuesta a la escasez de direcciones IPv4.
Su funcionamiento permite que múltiples sistemas con direcciones privadas compartan una o varias direcciones públicas. Para conseguirlo, el dispositivo NAT mantiene información sobre las conexiones y relaciona direcciones y puertos internos con los utilizados hacia el exterior.
Microsoft explica, por ejemplo, que su implementación NAT utiliza una tabla de flujos para dirigir el tráfico recibido desde una dirección y puerto externos hacia el endpoint interno correspondiente, que puede ser una máquina virtual, un ordenador o un contenedor.
En Linux entra en juego conntrack, el sistema de seguimiento de conexiones utilizado por netfilter. El kernel mantiene estructuras donde registra los flujos activos y ofrece parámetros específicos para gestionar el número de entradas, tablas hash y estados de las conexiones.
NatJack explota comportamientos asociados precisamente a este tipo de mecanismos.
Según Synack, muchas implementaciones se desarrollaron bajo una premisa razonable para las redes tradicionales: los equipos que comparten una tabla NAT pertenecen al mismo entorno y, por tanto, existe cierto nivel de confianza entre ellos.
La infraestructura actual es muy diferente.
Un mismo servidor físico puede ejecutar máquinas virtuales de distintos clientes. Kubernetes puede mantener decenas o cientos de contenedores con diferentes niveles de confianza. Un proveedor cloud puede compartir componentes de red entre múltiples cargas y un entorno de desarrollo puede ejecutar software procedente de fuentes externas.
La frontera entre red interna y red confiable se ha vuelto mucho menos clara.
Los investigadores probaron implementaciones desarrolladas independientemente y encontraron que todas las evaluadas eran susceptibles a una o varias de las técnicas de NatJack. Entre los sistemas analizados aparecen implementaciones utilizadas por Windows, Linux y macOS.
Que aparezca un comportamiento similar en código desarrollado por fabricantes diferentes es precisamente una de las razones por las que los investigadores hablan de una clase de ataques y no de una única vulnerabilidad.
Cuatro ataques: TCP, DNS, puertos y denegación de servicio
NatJack reúne cuatro técnicas con consecuencias diferentes.
La primera permite, bajo las condiciones necesarias para la explotación, secuestrar una conexión TCP activa que atraviese una implementación NAT afectada.
Esto puede resultar especialmente problemático cuando el protocolo utilizado sobre TCP no dispone de su propio cifrado y autenticación. En comunicaciones protegidas correctamente mediante TLS, tomar control del flujo de red no equivale automáticamente a poder descifrar o modificar con éxito el contenido de la sesión.
La segunda técnica está relacionada con DNS.
NatJack puede utilizarse para envenenar respuestas DNS basadas en UDP, intentando introducir una respuesta manipulada en lugar de la legítima. Un ataque de este tipo podría redirigir posteriormente determinadas comunicaciones hacia destinos controlados por un atacante si se cumplen el resto de condiciones necesarias.
La tercera técnica permite obtener información sobre los puertos que el dispositivo NAT ha asignado a conexiones pertenecientes a otros sistemas.
Conocer estos datos puede ayudar a preparar otros ataques al reducir la incertidumbre sobre cómo el NAT está traduciendo las comunicaciones.
La cuarta abandona el objetivo de interceptar tráfico y se centra en la disponibilidad.
Un atacante puede intentar agotar la tabla NAT, consumiendo las entradas disponibles hasta impedir o dificultar la creación de nuevas conexiones. En Linux, por ejemplo, el propio subsistema conntrack mantiene un contador del número de entradas de flujo asignadas y dispone de límites configurables para la tabla.
En ese escenario, NatJack puede convertirse en un vector de denegación de servicio contra la conectividad proporcionada por el dispositivo afectado.
| Técnica NatJack | Posible consecuencia |
|---|---|
| Secuestro TCP | Interferir en una conexión activa |
| Envenenamiento DNS | Introducir respuestas DNS manipuladas |
| Descubrimiento de puertos | Identificar asignaciones NAT de otras conexiones |
| Agotamiento de tabla | Provocar problemas de conectividad o denegación de servicio |
Dos CVE confirmadas y un problema más amplio
La investigación ha desembocado hasta ahora en la asignación de dos identificadores CVE.
El primero es CVE-2026-56181, relacionado con la implementación NAT de Microsoft Windows utilizada con Hyper-V.
Hyper-V permite crear redes virtuales NAT para proporcionar conectividad a máquinas virtuales utilizando la dirección IP y puertos del host mediante un switch virtual interno. Microsoft señala además que este modelo es habitual en tecnologías de contenedores.
La segunda vulnerabilidad es CVE-2026-63913, asociada al subsistema conntrack de netfilter en Linux.
Synack sitúa las puntuaciones CVSS de las vulnerabilidades identificadas entre 7,2 y 9,6, es decir, entre severidad alta y crítica según los casos.
La divulgación coordinada continúa, por lo que podrían aparecer avisos adicionales de fabricantes y nuevos identificadores CVE.
Pero las propias CVE no explican completamente NatJack.
Una vulnerabilidad convencional puede estar causada por un error muy concreto: una validación incorrecta, un desbordamiento de memoria o una función implementada de forma insegura. Corregir el código elimina entonces el problema.
Aquí la investigación apunta a algo más amplio: diferentes desarrolladores habrían llegado a comportamientos vulnerables partiendo de una misma concepción sobre cómo debe funcionar y en quién puede confiar un NAT.
Por esa razón no existe una actualización universal que pueda instalarse para considerar resuelto NatJack en cualquier infraestructura.
Cloud, Kubernetes y virtualización cambian el nivel de riesgo
La investigación adquiere especial relevancia en los centros de datos modernos.
Una red corporativa tradicional podía tener decenas de ordenadores relativamente controlados detrás de un firewall. En una infraestructura cloud, el mismo concepto puede aplicarse a miles de cargas virtualizadas que aparecen y desaparecen automáticamente.
Synack identifica como áreas potencialmente afectadas routers y firewalls, Docker, Kubernetes, Hyper-V, gateways NAT cloud, bridges y switches virtuales, además de servicios públicos de contenedores y virtualización.
La existencia de NAT en uno de estos entornos no implica por sí misma una vulnerabilidad explotable.
La cuestión que deberían analizar los administradores es otra: qué sistemas comparten la tabla NAT y qué nivel de confianza existe entre ellos.
El escenario de mayor interés sería aquel en el que una carga no confiable comparte infraestructura NAT con máquinas virtuales, contenedores o servicios sensibles.
Un proveedor que ejecuta infraestructura multi-tenant tiene un problema distinto al de una pequeña empresa en la que todos los equipos pertenecen a la misma organización. También cambia el riesgo en plataformas que permiten a usuarios ejecutar contenedores, código o máquinas virtuales propias.
Este enfoque encaja con una tendencia más amplia de la seguridad moderna: dejar de considerar automáticamente fiable cualquier sistema simplemente porque se encuentra dentro de una determinada red.
No existe un parche único para NatJack
Algunas implementaciones ya cuentan con cambios destinados a dificultar la explotación.
Synack cita las versiones 6.6.142 y posteriores del kernel Linux, así como FreeBSD 15.0 y posteriores, entre las actualizaciones disponibles. Sin embargo, los investigadores advierten de que estas medidas elevan la dificultad del ataque pero no eliminan completamente la cuestión de diseño que está detrás de NatJack.
Por eso la mitigación no debería limitarse a comprobar la versión del sistema operativo.
Synack recomienda cifrar tanto el tráfico externo como las comunicaciones internas, utilizar TLS siempre que sea posible y proteger DNS mediante tecnologías como DNSSEC y DNS cifrado.
La segmentación es otra medida importante.
Las máquinas virtuales y contenedores no confiables deberían separarse de las cargas sensibles, especialmente cuando compartirían la misma infraestructura NAT. También se recomienda evitar NAT compartido entre entornos con diferentes niveles de confianza cuando la arquitectura permita hacerlo.
Protecciones como IP Source Guard pueden dificultar determinados escenarios de suplantación, mientras que limitar privilegios y capacidades de red reduce las posibilidades de que una carga comprometida genere el tráfico necesario.
Finalmente está la monitorización.
Un crecimiento anormal de la tabla NAT, patrones extraños de paquetes o un consumo inesperado de entradas de seguimiento de conexiones pueden convertirse en señales útiles para detectar determinadas técnicas. En Linux existen métricas como nf_conntrack_count, que permite conocer el número de entradas de flujo actualmente asignadas.
NatJack no significa que NAT haya dejado repentinamente de ser utilizable ni que millones de routers deban desconectarse. La investigación apunta a un problema más específico: una tecnología diseñada cuando compartir red implicaba cierto grado de confianza se utiliza ahora para separar cargas que pueden no confiar en absoluto unas en otras.
En infraestructuras cloud, virtualizadas y de contenedores, esa diferencia obliga a revisar dónde termina realmente una frontera de seguridad.
Preguntas frecuentes
¿Qué es NatJack?
NatJack es una clase de ataques descubierta por Malcolm Stagg que explota determinadas suposiciones de confianza en implementaciones NAT. Puede utilizarse para atacar conexiones TCP, respuestas DNS, asignaciones de puertos o la disponibilidad de las tablas NAT.
¿NatJack afecta a Windows y Linux?
Las pruebas encontraron comportamientos afectados en implementaciones independientes utilizadas por Windows, Linux y macOS. Hasta ahora se han asignado CVE-2026-56181 para Windows NAT en Hyper-V y CVE-2026-63913 para netfilter conntrack en Linux.
¿Todos los dispositivos que utilizan NAT pueden ser atacados?
No necesariamente. La posibilidad práctica de explotación depende de la implementación y de la arquitectura de red, especialmente de si cargas no confiables pueden compartir infraestructura NAT con sistemas de confianza.
¿Existe un parche definitivo contra NatJack?
No existe un único parche que elimine toda la clase de ataques en todas las implementaciones. Synack recomienda combinar actualizaciones con cifrado, segmentación, separación de cargas con distintos niveles de confianza y monitorización del comportamiento de NAT.
Fuentes:
- Synack Security Research, NatJack: A New Attack Class Exploiting Trust in Network Address Translation, agosto de 2026.
