Introducción
Durante treinta años, el NAT ha ejercido un papel discreto pero fundamental en la arquitectura de red de las empresas. Detrás de las siglas —Network Address Translation— se esconde un supuesto tácito que pocas organizaciones han cuestionado: las máquinas que comparten la misma tabla NAT pueden considerarse de confianza mutua. Es precisamente ese supuesto el que NatJack acaba de demoler.
Cuando el perímetro de red se convierte en una ilusión
Presentadas en Black Hat USA 2026 por el investigador Malcolm Stagg, las técnicas NatJack no explotan un fallo puntual en una implementación concreta, sino una vulnerabilidad arquitectónica inscrita en el propio diseño del NAT. La demostración es contundente: de 32 productos y configuraciones evaluados con 13 proveedores distintos, todos resultaron vulnerables a al menos una de las técnicas de la familia NatJack.
La condición de ataque es relativamente accesible: el atacante debe compartir la misma frontera NAT que su objetivo. En entornos de oficina compartida, infraestructuras Hyper-V multi-tenant, clústeres de contenedores o nubes privadas, este escenario está lejos de ser excepcional.
Cuatro técnicas, un único punto ciego
El arsenal NatJack se articula en cuatro vectores diferenciados:
- Secuestro de sesiones TCP activas: manipulando las entradas de la tabla NAT, el atacante puede forzar el cierre de una conexión establecida para luego tomar el control de esa sesión.
- Envenenamiento DNS: las consultas UDP que circulan dentro del perímetro NAT compartido pueden interceptarse y sus respuestas falsificarse, exponiendo a los clientes a redirecciones silenciosas.
- Descubrimiento de puertos mapeados: es posible identificar qué puertos externos corresponden a las conexiones activas de otros clientes, allanando el camino para ataques posteriores dirigidos.
- Saturación de la tabla NAT: inyectando masivamente flujos ficticios, el atacante impide que los clientes legítimos puedan establecer nuevas conexiones — una denegación de servicio encubierta, difícilmente distinguible de una sobrecarga ordinaria.
Se han asignado dos CVE para las implementaciones más extendidas: CVE-2026-56181 para el NAT de Windows utilizado por Hyper-V (CVSS 8.3) y CVE-2026-63913 para Linux Netfilter conntrack (CVSS 8.2). Existen parches para ambos casos específicos: en Linux, a través de las ramas estables 5.10.259, 5.15.210 y 6.1.176; en Windows, mediante las actualizaciones de seguridad publicadas este verano.
Lo que esto cambia para los equipos de red
El punto crítico es el siguiente: NatJack no es una vulnerabilidad que un parche baste para solucionar en su totalidad. El problema es de naturaleza conceptual. El NAT fue diseñado para traducir direcciones, no para aislar inquilinos. Mientras cargas de trabajo no controladas compartan la misma tabla NAT que sistemas sensibles, el riesgo estructural permanece.
Para los equipos de red y seguridad, las implicaciones prácticas son claras:
- La segmentación VLAN y el aislamiento de puertos de conmutador no ofrecen protección frente a NatJack, que opera en las capas 3 y 4 del modelo de red.
- Generalizar el cifrado de los flujos internos —TLS sistemático, arquitectura de confianza cero— sigue siendo la defensa más sólida contra el secuestro de sesiones y el envenenamiento DNS.
- IP Source Guard puede limitar la inyección de flujos forjados en origen.
- Las arquitecturas Hyper-V o de nube privada deben separar las cargas de trabajo no confiables en pasarelas NAT independientes, en lugar de confiar en un aislamiento lógico dentro de una misma tabla.
El supuesto de confianza que nadie cuestiona
Lo que NatJack pone de manifiesto, en el fondo, es un punto ciego sistémico: los equipos de TI heredan hipótesis de seguridad implícitas grabadas en protocolos diseñados hace décadas, y las trasladan a contextos para los que jamás fueron concebidos. El NAT como frontera de confianza es una convención, no una garantía.
Para los CIO y CISO que operan en entornos multi-tenant —virtualización, contenedores o nube híbrida— NatJack es un recordatorio inequívoco: la arquitectura de red debe rediseñarse desde el axioma de que los co-inquilinos son potencialmente hostiles, y no benignos por defecto.