La librería estándar de Elixir procesa literales enteros JSON sin límite de longitud, permitiendo bloquear schedulers con payloads de pocos megabytes antes de cualquier validación de identidad.
Una falla en el módulo JSON de la librería estándar de Elixir permite a atacantes no autenticados causar denegación de servicio mediante agotamiento de CPU y memoria en aplicaciones que procesan documentos JSON. La vulnerabilidad, identificada como CVE-2026-115274, afecta las versiones 1.18.0-rc.0 a 1.18.5, 1.19.0-rc.0 a 1.19.6, y 1.20.0-rc.0 a 1.20.4 del lenguaje. El equipo de Elixir publicó parches en las versiones 1.18.6, 1.19.7 y 1.20.5.
El problema radica en que las funciones JSON.decode/1 y JSON.decode!/1 convierten cada literal entero usando erlang:binary_to_integer/1 sin validar su longitud. Un literal de un millón de dígitos se decodifica correctamente pero consume entre 100 y 300 veces más CPU que una cadena de la misma longitud. En términos prácticos, un cuerpo de solicitud de algunos megabytes puede bloquear un scheduler de Erlang durante aproximadamente un segundo. Literales de más de 1.29 millones de dígitos generan SystemLimitError, interrumpiendo el procesamiento.
El punto de entrada sin autenticación en aplicaciones Phoenix
La criticidad de esta vulnerabilidad se amplifica por la arquitectura predeterminada de las aplicaciones Phoenix generadas con phx.new. Estas aplicaciones decodifican cuerpos de solicitud JSON en Plug.Parsers, una etapa del pipeline que se ejecuta antes del enrutamiento y la autenticación. Esto significa que un atacante no autenticado puede enviar un payload malicioso directamente al parser JSON sin necesidad de credenciales válidas ni de alcanzar ningún endpoint específico de la aplicación.
La secuencia de procesamiento típica en Phoenix coloca el parseo de JSON como una de las primeras operaciones sobre la solicitud HTTP entrante. Cuando Plug.Parsers recibe un cuerpo con Content-Type application/json, invoca el decodificador JSON de Elixir antes de que la solicitud pase por middlewares de autenticación o llegue al router. Esta decisión de diseño, razonable para la mayoría de los casos de uso legítimos, se convierte en un vector de ataque cuando el parser mismo es vulnerable a inputs malformados.
Un atacante puede construir un documento JSON con un literal entero de un millón de dígitos en un payload de tres a cinco megabytes. Al enviar múltiples solicitudes concurrentes de este tipo a un servidor Phoenix vulnerable, cada una bloquea un scheduler durante aproximadamente un segundo. En un sistema con schedulers limitados (típicamente uno por núcleo de CPU), esto degrada rápidamente la capacidad de respuesta del servidor hasta hacerlo inoperable para usuarios legítimos.
Asimetría de recursos entre atacante y víctima
La vulnerabilidad presenta una asimetría de recursos característica de los ataques de denegación de servicio efectivos. El costo para el atacante es mínimo: generar un literal de un millón de dígitos es trivial, y el payload resultante cabe en una solicitud HTTP estándar. El costo para el servidor víctima es desproporcionado: cada solicitud maliciosa consume recursos de CPU equivalentes a procesar entre 100 y 300 megabytes de datos de cadena convencionales.
Esta desproporción se debe a la complejidad algorítmica de binary_to_integer/1 cuando opera sobre literales extremadamente largos. La conversión de una secuencia de dígitos ASCII a su representación entera interna requiere operaciones aritméticas que escalan de manera no lineal con la longitud del input. Mientras que el parseo de una cadena JSON de un millón de caracteres es una operación relativamente económica (principalmente copia de memoria), la conversión de un millón de dígitos a un entero involucra multiplicaciones y sumas acumulativas que saturan la CPU.
El límite de 1.29 millones de dígitos que genera SystemLimitError corresponde a restricciones internas de la máquina virtual de Erlang sobre el tamaño de términos individuales. Sin embargo, este límite no protege contra el ataque: un atacante racional se mantiene por debajo de ese umbral para maximizar el agotamiento de recursos sin provocar errores que podrían facilitar la detección o el filtrado automático.
Exposición en ecosistemas de microservicios en América Latina
La adopción de Elixir y Phoenix en América Latina ha crecido particularmente en sectores fintech y de comercio electrónico, donde la concurrencia y la tolerancia a fallos de la plataforma BEAM (la máquina virtual de Erlang) resultan atractivas. Empresas en Brasil, Argentina y México han migrado componentes críticos de sus arquitecturas de microservicios a Phoenix, a menudo exponiendo APIs JSON públicas para aplicaciones móviles y servicios de terceros.
En estos contextos, la vulnerabilidad CVE-2026-115274 representa un riesgo operacional directo. Un API Gateway basado en Phoenix que procesa solicitudes de millones de usuarios móviles puede ser degradado por un atacante con recursos mínimos. La ausencia de autenticación previa al parseo significa que incluso endpoints públicos de registro o consulta de catálogo — diseñados para ser accesibles sin credenciales — se convierten en vectores de ataque.
La dependencia de versiones específicas de Elixir en estos entornos complica la mitigación. Muchas organizaciones en la región operan con políticas de actualización conservadoras, especialmente en sistemas de producción críticos. La necesidad de actualizar a versiones parcheadas (1.18.6, 1.19.7 o 1.20.5) puede requerir ciclos de prueba y validación que demoran semanas, dejando sistemas expuestos durante ese período. Además, la naturaleza de la vulnerabilidad — un problema en la librería estándar, no en código de aplicación — dificulta la implementación de workarounds efectivos sin modificar el runtime de Elixir.
Nuestro análisis
CVE-2026-115274 ilustra un patrón recurrente en vulnerabilidades de parseo: la asunción implícita de que los inputs maliciosos serán detectados por validaciones de negocio posteriores, sin considerar que el acto mismo de parsear puede ser el vector de ataque. La decisión de procesar JSON antes de la autenticación en Phoenix no es un error de diseño en sí misma — responde a la necesidad de acceder al cuerpo de la solicitud para determinar cómo enrutarla — pero crea una superficie de ataque que esta vulnerabilidad explota.
La ausencia de límites en la longitud de literales enteros en JSON.decode/1 refleja una confianza en que los documentos JSON de entrada serán razonablemente formados. Esta confianza es incompatible con la realidad de servicios expuestos a internet público. Comparado con parsers JSON en otros lenguajes que implementan límites de profundidad, tamaño de cadenas o complejidad de anidamiento, el módulo JSON de Elixir carecía de defensas contra inputs patológicos diseñados para maximizar el consumo de recursos.
El impacto de esta vulnerabilidad se amplifica en arquitecturas donde Phoenix actúa como punto de entrada único para múltiples servicios backend. Un ataque exitoso no solo degrada el servicio Phoenix en sí, sino que puede propagar latencia y timeouts a toda la cadena de dependencias, generando fallos en cascada difíciles de diagnosticar sin visibilidad específica sobre el consumo de CPU por solicitud en el parser JSON.
¿Cuántas aplicaciones Phoenix en producción en América Latina permanecerán vulnerables porque sus equipos de operaciones no monitorean CVEs de la librería estándar de Elixir con la misma atención que dedican a dependencias de terceros?