Una investigación presentada en Black Hat USA 2026 ha identificado NatJack, una nueva clase de ataques contra Network Address Translation (NAT) que no depende de una vulnerabilidad concreta de software, sino de cómo distintas implementaciones gestionan las conexiones y la confianza entre sistemas que comparten una tabla NAT. Las pruebas realizadas por el investigador Malcolm Stagg encontraron comportamientos afectados en Windows, Linux y macOS, mientras que dos fallos relacionados ya cuentan con identificadores CVE.
Las claves de NatJack en 30 segundos
- NatJack reúne cuatro técnicas para manipular el funcionamiento de implementaciones NAT.
- Puede permitir secuestrar conexiones TCP, alterar respuestas DNS, descubrir puertos asignados y agotar tablas NAT.
- Las pruebas detectaron comportamientos afectados en código independiente de Windows, Linux y macOS.
- Ya existen dos identificadores: CVE-2026-56181 y CVE-2026-63913, con puntuaciones CVSS entre 7,2 y 9,6.
- No existe un parche universal: cloud, Kubernetes y entornos multi-tenant requieren especial atención.
NatJack ha sido desarrollado durante varios años por Malcolm Stagg, investigador de SODIUM-24 y miembro del Synack Red Team. El trabajo fue presentado en Black Hat USA 2026 bajo el título Breaking Trust Boundaries: Exploiting Design Assumptions in Network Infrastructure.
La parte más relevante para administradores de sistemas y responsables de infraestructura es que NatJack no debe interpretarse simplemente como otra vulnerabilidad de un router.
NAT aparece actualmente dentro de hipervisores, hosts de contenedores, Kubernetes, gateways cloud, firewalls, bridges virtuales y otros componentes de red. Una misma tabla puede terminar gestionando conexiones pertenecientes a máquinas virtuales o cargas de trabajo con niveles de confianza completamente diferentes.
Ahí es donde una decisión de diseño heredada de las primeras décadas de Internet adquiere nuevas implicaciones.
El problema no es NAT, sino quién comparte su tabla
NAT nació fundamentalmente para permitir que varios dispositivos con direcciones privadas pudieran comunicarse con Internet utilizando una cantidad mucho menor de direcciones IPv4 públicas.
Para mantener las comunicaciones, el dispositivo encargado de realizar NAT necesita saber qué conexión corresponde a cada sistema.
En términos simplificados, cuando una máquina con una dirección privada inicia una conexión hacia Internet, NAT puede modificar la dirección y el puerto de origen. Mantiene después información de esa traducción para que las respuestas puedan regresar al dispositivo correcto.
Un ejemplo simplificado sería:
Servidor A
10.0.0.10:49152
│
▼
┌─────────────────────────┐
│ NAT Gateway │
│ │
│ 10.0.0.10:49152 │
│ ↕ │
│ 203.0.113.10:62001 │
└─────────────────────────┘
│
▼
InternetLa implementación necesita mantener estados, asignaciones de puertos y seguimiento de conexiones para que este mecanismo funcione.
En Linux, una pieza fundamental es netfilter conntrack, que mantiene información sobre los flujos activos. Windows dispone igualmente de mecanismos NAT utilizados, entre otros escenarios, por Hyper-V y tecnologías de virtualización.
La investigación de NatJack parte de una pregunta sencilla: ¿qué ocurre si uno de los sistemas que comparte esa infraestructura NAT intenta manipular deliberadamente su comportamiento?
Según Synack, históricamente muchas implementaciones han asumido cierto nivel de confianza entre los dispositivos situados detrás de la misma tabla NAT.
En un centro de datos actual esa premisa puede dejar de ser válida.
Cuatro técnicas de ataque diferentes
Stagg ha documentado cuatro técnicas dentro de NatJack, cada una dirigida a una parte diferente del funcionamiento de NAT.
La primera permite intentar secuestrar conexiones TCP activas.
El atacante busca manipular el estado que NAT mantiene sobre una conexión existente para interferir en el tráfico de otro sistema. Las consecuencias dependen también del protocolo superior utilizado: controlar un flujo TCP no implica automáticamente romper el cifrado TLS que pueda proteger la sesión.
La segunda técnica afecta a DNS sobre UDP.
NatJack puede utilizar determinadas características del seguimiento de conexiones para intentar introducir respuestas DNS manipuladas. Si el ataque tiene éxito y no existen otras protecciones, un sistema podría aceptar una respuesta falsa y resolver un dominio hacia una dirección controlada por el atacante.
La tercera técnica permite identificar qué puerto externo ha asignado NAT a una conexión perteneciente a otra carga.
Esta información puede resultar útil para reducir el espacio de búsqueda necesario en otros ataques.
La cuarta técnica tiene un objetivo diferente: agotar los recursos disponibles.
Los dispositivos NAT mantienen un número limitado de entradas para seguir conexiones. Un atacante capaz de generar suficientes estados puede intentar llenar la tabla NAT o conntrack, dificultando o impidiendo la creación de nuevas conexiones y provocando una denegación de servicio.
| Técnica | Objetivo |
|---|---|
| TCP hijacking | Interferir o tomar control de conexiones TCP activas |
| DNS poisoning | Introducir respuestas DNS falsas |
| Port discovery | Descubrir puertos asignados a otras conexiones |
| NAT exhaustion | Saturar la tabla NAT y afectar a la conectividad |
No todas las técnicas funcionarán en cualquier dispositivo ni tendrán las mismas consecuencias. La explotación depende de la implementación, configuración, topología y capacidades que tenga el sistema atacante.
Hyper-V y netfilter ya tienen CVE
La divulgación coordinada ha producido hasta ahora dos identificadores públicos.
CVE-2026-56181 afecta al NAT de Microsoft Windows utilizado en entornos Hyper-V.
La segunda, CVE-2026-63913, está relacionada con el subsistema conntrack de netfilter en Linux.
Synack sitúa las puntuaciones CVSS asociadas a los problemas identificados entre 7,2 y 9,6, desde severidad alta hasta crítica.
La existencia de dos CVE en plataformas diferentes es importante porque ayuda a mostrar la naturaleza del problema.
No se trata de que Windows y Linux compartan el mismo código defectuoso. Sus implementaciones se han desarrollado de forma independiente.
La investigación también ha identificado comportamientos vulnerables en macOS.
Synack considera por ello que NatJack representa una clase de ataques contra determinadas suposiciones de diseño de NAT, en lugar de una vulnerabilidad limitada a una función concreta.
La divulgación continúa y podrían aparecer nuevos avisos de fabricantes o identificadores CVE adicionales.
Por qué Kubernetes y los entornos cloud merecen atención
El escenario probablemente más interesante para NatJack no está en una red doméstica, sino en las infraestructuras multi-tenant.
Un servidor moderno puede ejecutar decenas o cientos de máquinas virtuales o contenedores.
┌──────────────┐
│ VM cliente A │──┐
└──────────────┘ │
│
┌──────────────┐ │ ┌─────────────┐
│ VM cliente B │──┼─────▶│ Shared NAT │────▶ Internet
└──────────────┘ │ └─────────────┘
│
┌──────────────┐ │
│ Contenedor X │──┘
└──────────────┘Si todos esos sistemas pertenecen al mismo administrador y tienen un nivel de confianza similar, el riesgo es diferente.
Pero un cloud público, una plataforma Kubernetes compartida o un servicio que permita ejecutar código de terceros puede tener cargas confiables y no confiables utilizando componentes NAT comunes.
Synack identifica entre los entornos que deberían revisar su exposición los routers y firewalls, Docker, Kubernetes, Hyper-V, gateways NAT cloud, bridges y switches virtuales y servicios públicos de contenedores y virtualización.
Esto no significa que cualquier clúster Kubernetes sea vulnerable a un ataque práctico.
La pregunta que debe hacerse el administrador es más concreta:
¿puede una carga controlada por un usuario no confiable compartir la misma infraestructura NAT con sistemas sensibles?
Si la respuesta es afirmativa, NatJack merece una revisión más detallada.
Una tabla conntrack también puede convertirse en un recurso atacable
Para administradores Linux, el componente especialmente relevante es conntrack.
El kernel utiliza este subsistema para mantener información sobre conexiones y dispone de parámetros que permiten consultar y limitar el número de entradas.
Entre ellos aparecen:
nf_conntrack_count
nf_conntrack_max
nf_conntrack_bucketsnf_conntrack_count indica el número de entradas actualmente asignadas, mientras nf_conntrack_max establece el máximo permitido.
Una infraestructura en la que el número de conexiones comienza a aproximarse de forma inesperada al límite puede sufrir problemas para establecer nuevos flujos.
NatJack convierte este comportamiento en uno de sus posibles vectores de ataque mediante el agotamiento deliberado de la tabla.
Para equipos de operaciones, esto significa que las métricas de conntrack no deberían considerarse únicamente un indicador de rendimiento. En determinados entornos pueden convertirse también en una señal de seguridad.
Picos anormales de conexiones, utilización inusual de tablas NAT o determinados patrones de paquetes pueden justificar una investigación adicional.
No existe un parche que solucione NatJack en todas partes
Esta es probablemente la característica que más diferencia NatJack de una vulnerabilidad convencional.
No existe un paquete que pueda instalarse y permita considerar resuelto el problema en cualquier infraestructura.
Synack señala que algunas actualizaciones ya incorporan medidas que dificultan determinadas técnicas. Entre ellas menciona Linux kernel 6.6.142 y posteriores y FreeBSD 15.0 y posteriores.
Pero esas modificaciones no eliminan la cuestión general de diseño.
Cada fabricante tendrá que revisar su propia implementación y decidir qué cambios introduce en asignación de puertos, seguimiento de conexiones, validación de paquetes y otros componentes relacionados.
El proceso podría prolongarse mientras continúe la divulgación coordinada.
Por eso las mitigaciones arquitectónicas tienen tanto peso como las actualizaciones.
Qué pueden hacer los administradores
La primera recomendación es mantener actualizados kernels, hipervisores, sistemas operativos, firewalls y gateways. Pero NatJack obliga a mirar también la arquitectura de red.
Synack recomienda evitar que cargas con diferentes niveles de confianza compartan infraestructura NAT siempre que sea posible.
La segmentación puede aplicarse separando redes, gateways o dominios de seguridad para impedir que un contenedor o máquina virtual no confiable tenga acceso al mismo contexto NAT que sistemas sensibles.
También debería cifrarse el tráfico interno.
TLS suele darse por supuesto para las comunicaciones hacia Internet, pero todavía existen redes privadas donde determinados servicios internos funcionan sin cifrado porque se considera que estar dentro de la red es suficiente protección.
NatJack es otro ejemplo de por qué esa confianza implícita resulta problemática.
Para DNS, Synack recomienda considerar DNSSEC y DNS cifrado, mientras mecanismos como IP Source Guard pueden ayudar a reducir determinados escenarios de suplantación.
También resulta conveniente limitar las capacidades de red y privilegios disponibles para contenedores y cargas que no los necesiten.
Finalmente, los responsables de infraestructura pueden monitorizar utilización de tablas NAT y conntrack, patrones anómalos de paquetes y cambios inesperados en el número de conexiones.
La conclusión técnica de NatJack no es que NAT esté roto y deba desaparecer. Es más específica: NAT no debería tratarse automáticamente como una frontera de seguridad entre cargas que no confían unas en otras.
Ese matiz importa especialmente en 2026. Una tecnología creada para compartir direcciones IPv4 forma ahora parte de hipervisores, plataformas de contenedores y clouds donde sistemas pertenecientes a usuarios diferentes pueden ejecutarse sobre la misma infraestructura.
NatJack demuestra que algunas decisiones tomadas cuando esos escenarios todavía no existían necesitan volver a examinarse.
Preguntas frecuentes
¿Qué es NatJack?
NatJack es una clase de ataques descubierta por Malcolm Stagg que aprovecha determinados comportamientos y supuestos de confianza presentes en implementaciones NAT. Incluye técnicas contra TCP, DNS, asignación de puertos y disponibilidad de las tablas NAT.
¿Qué sistemas están afectados por NatJack?
Las pruebas encontraron comportamientos vulnerables en implementaciones desarrolladas independientemente para Windows, Linux y macOS. El riesgo concreto depende de la implementación, configuración y arquitectura de cada entorno.
¿Qué CVE están relacionadas con NatJack?
Hasta ahora se han asignado CVE-2026-56181, relacionada con Windows NAT en Hyper-V, y CVE-2026-63913, asociada a netfilter conntrack en Linux. La divulgación coordinada continúa.
¿Cómo se puede mitigar NatJack?
Además de instalar las actualizaciones disponibles, Synack recomienda cifrar comunicaciones internas y externas, separar cargas confiables y no confiables, evitar NAT compartido entre distintos niveles de confianza, proteger DNS, limitar privilegios y monitorizar el comportamiento de las tablas NAT.
Fuentes:
- Synack Security Research, NatJack: A New Attack Class Exploiting Trust in Network Address Translation, agosto de 2026.
