La vulnerabilidad crítica CVE-2025-11953, apodada de forma no oficial Metro4Shell, está siendo explotada activamente para comprometer entornos de desarrollo de React Native. El fallo reside en Metro server, el empaquetador JavaScript predeterminado de React Native, y permite a atacantes desplegar cargas maliciosas en Windows y Linux, utilizando como puerta de entrada los propios sistemas de los desarrolladores.
Qué es Metro server y por qué se ha convertido en un objetivo de alto valor
Metro es el servidor de bundling que React Native utiliza por defecto para empaquetar y servir código JavaScript durante el desarrollo. Para ello levanta un servidor HTTP local que, en la práctica, puede vincularse no solo a localhost, sino también a interfaces de red accesibles desde el exterior. Sobre este servidor se exponen múltiples endpoints HTTP pensados originalmente para un uso local y controlado por el desarrollador.
El problema aparece cuando, por motivos de configuración de la IDE, VPN, proxies inversos o entornos en la nube, ese Metro server termina siendo accesible desde Internet o desde redes corporativas amplias. En ese momento, un componente supuestamente “de desarrollo” pasa a comportarse como un servicio de producción expuesto, con una relevancia similar a cualquier aplicación web vulnerable en el perímetro de la organización.
CVE-2025-11953 (Metro4Shell): explotación a través del endpoint /open-url
La vulnerabilidad fue identificada por investigadores de JFrog en noviembre de 2025. El análisis reveló que el endpoint /open-url de Metro server acepta peticiones HTTP POST con URLs arbitrarias y las pasa directamente a la función open() sin validación ni saneamiento. Este diseño permite que un atacante remoto, sin autenticación, pueda forzar la ejecución de comandos o binarios en la máquina donde se está ejecutando el servidor.
Ataques observados en Windows: PowerShell y binarios en Rust empaquetados con UPX
Según datos de VulnCheck, los primeros casos confirmados de explotación de CVE-2025-11953 se detectaron el 21 de diciembre de 2025, con nuevos incidentes el 4 y el 21 de enero. En estas campañas, los atacantes enviaban peticiones HTTP POST al endpoint /open-url con cuerpos que contenían scripts de PowerShell codificados en base64.
Una vez decodificado y ejecutado, el script descargaba y lanzaba una carga maliciosa para Windows: un binario en Rust empaquetado con UPX, que incluía técnicas básicas de evasión de análisis (ofuscación, comprobaciones de entorno y medidas antiestáticas y antidinámicas). Los investigadores encontraron además un binario equivalente para Linux alojado en la misma infraestructura, lo que evidencia una campaña claramente multiplataforma.
Impacto en Linux y macOS: ejecución de binarios y punto de partida para el movimiento lateral
En sistemas Linux y macOS, las limitaciones del entorno hacen que la explotación de Metro4Shell no siempre proporcione una línea de comandos completamente arbitraria. Sin embargo, sí permite ejecutar ficheros binarios, lo que resulta suficiente para desplegar loaders, criptomineros, troyanos de acceso remoto (RAT) o implantes que faciliten el movimiento lateral dentro de la red corporativa.
Versiones afectadas, alcance y exposición en Internet
El fallo afecta al paquete @react-native-community/cli-server-api en las versiones desde la 4.8.0 hasta la 20.0.0-alpha.2. La corrección se introdujo en la versión estable 20.0.0, donde se ha rediseñado la lógica del endpoint /open-url endureciendo el tratamiento de URLs externas.
Una revisión mediante el motor de búsqueda de banners ZoomEye indica la presencia de alrededor de 3500 Metro servers de React Native expuestos públicamente. Detrás de estos servicios pueden encontrarse tanto desarrolladores independientes como empresas que utilizan React Native para aplicaciones móviles críticas, ampliando de forma significativa la superficie potencial de ataque.
Entornos de desarrollo como nuevo frente de ataque para los adversarios
El caso de Metro4Shell refuerza un patrón cada vez más visible: cuando un servicio de desarrollo se expone a redes no confiables, pasa de facto a formar parte de la infraestructura de producción. Situaciones similares se producen con sistemas como Jenkins, GitLab Runner, plataformas de CI/CD, paneles de administración de prueba o entornos de staging mal protegidos.
Estos servicios suelen configurarse con el criterio de “que funcione cuanto antes”, sin políticas estrictas de autenticación, segmentación o monitorización. Como resultado, se convierten en objetivos especialmente atractivos: al comprometer la estación de trabajo de un desarrollador, un atacante puede acceder a código fuente, tokens de acceso, claves, configuraciones de VPN y, desde ahí, escalar hacia segmentos más sensibles de la organización. Incidentes de la cadena de suministro de software en los últimos años han demostrado repetidamente el impacto de vulnerar la capa de desarrollo y entrega de código.
Medidas de mitigación para Metro4Shell y buenas prácticas de DevSecOps
Para reducir el riesgo asociado a CVE-2025-11953 (Metro4Shell) y a vulnerabilidades similares en herramientas de desarrollo, resulta fundamental aplicar varias capas de protección:
1. Actualización inmediata de dependencias. Migrar @react-native-community/cli-server-api a la versión 20.0.0 o superior y mantener políticas estrictas de gestión de parches y dependencias (incluyendo escáneres de composición de software, SCA).
2. Restricción de la exposición de Metro server. Forzar la vinculación exclusiva a 127.0.0.1, evitar la publicación directa en Internet y, cuando sea necesario el acceso remoto, utilizar túneles seguros (SSH, VPN bien configuradas) en lugar de exponer puertos abiertos.
3. Segmentación de red y enfoque Zero Trust. Tratar los entornos de desarrollo como activos críticos, con segmentación de red, políticas de mínimo privilegio y controles de acceso adaptativos, alineados con un modelo Zero Trust.
4. Monitorización y detección temprana. Supervisar tráfico inusual hacia endpoints como /open-url, ejecuciones sospechosas de PowerShell y descargas de binarios desconocidos. Integrar estos eventos en soluciones SIEM y EDR para una respuesta rápida ante indicadores de compromiso.
Metro4Shell demuestra hasta qué punto se ha difuminado la frontera entre “herramientas internas de desarrollo” y “servicios en producción”. Mantener entornos de desarrollo inseguros deja de ser una simple concesión a la comodidad para convertirse en un riesgo directo de incidente grave. Una revisión sistemática de los servicios expuestos, la actualización constante de dependencias y la integración real de prácticas DevSecOps en el ciclo de vida de desarrollo son pasos esenciales para fortalecer la resiliencia frente a ataques dirigidos a la ecosistema React Native y a la cadena de suministro de software en general.
